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I am  going  lo  talk  to  you  about  the  application  of  microprocessors  to 
process  c ntrol.  My  perception  is  that  of  the  end-user  whose  objective 
is  to  increase  the  operating  efficiency  of  flow  processes  in  a refinery  or 
a batch  chemical  plant,  etc.  Our  methods  to  increase  operating  efficiency 
are  limited: 

. We  may  use  whips,  but  those  are  going  out  of  fashion. 

. Mechanization  - in  other  words,  the  replacement  of  muscle 
power  with  machine  power,  is  an  alternative. 

. We  may  want  to  improve  the  economy  of  scale  through 
increasing  the  size  of  production  units  or  increase 
their  integration  by  letting  material  flow  from  stage  Lo 
stage  without  being  touched  by  human  hands,  and  finally 

. We  can  increase  the  speed  of  operations. 


All  of  these  methods,  with  the  exception  of  whips  of  course,  imply  some 
level  of  automation.  That  is,  the  use  of  machines  to  operate  and/or  control 
other  machines. 


I'm  sure  many  of  you  are  familiar  with  the  following  definition  of  design: 
Given  a set  of  rules  of  behavior  ("The  Process")  and 
a set  of  components,  find  the  "best  compromise"  in  organizing 
components  into  a system.  ("The  Plant") 


Computers  as  components  of  flow  process  plants  fall  into  two  basic 
categories: 


1 
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■■■■■■■■ 


. Application  independent  (commercially  available,  no  customiza- 
tion required)  — in  other  words,  using  computers  as  hidden 
components  in  purchased  equipment  which  are  transparent 
to  us  as  users.  (For  example,  in  cathode  ray  tubes,  wrist 
watches,  etc.) 

. Application  dependent  (commercially  not  available,  customiza- 
tion required)  — that  is,  computers  used  for  new  functions 
sucli  as  direct  digital  control  of  batch  processes  or;  as 
replacement  alternatives  for  familiar  functions  which  we 
can  now  implement  cheaper.  (For  example,  one  may  replace 
relay  circuits  with  small  computers). 

From  tills  particular  point  of  view,  [will  focus  on  the  use  of  small 
computers  as  application  dependent  components  in  the  design  of  a flow  process 
plant  witli  the  eye  on  increasing  operating  efficiency. 

Before  I go  on  with  the  discussion  of  small  computers,  1 would  like  to 
distinguish  between  microprocessors  and  miniature  computers. 

A miniature  computer  is  something  like  a very  small  IBM  S3/0/l(i8  or  a 
CDC  Cyber  175  which  would  fit  in  your  briefcase  but  otherwise  can  do  all 
the  functions  of  its  bigger  brother.  By  microprocessor  I mean  the  "chip", 
i.e.  a collection  of  slow,  primitive,  computer  elements  (registers,  arithmetic 
unit,  and  control  logic)  on  one  monolithic  silicone  substrate  with  or  wilhouL 
memory,  optionally  purchasable  mounted  on  a printed  circuit  board. 


Of  course  If  somebody  bands  you  a small  box  and  you  can't  tell  whether 
it  Is  a minicomputer  or  a microprocessor  you  may  try  to  run  corporate  payroll 
In  that  box.  If  the  payroll  runs,  we  are  talking  of  a miniature  business 
computer.  If  not,  it  is  a microprocessor.  In  other  words,  try  a benchmark 
to  distinguish  between  a miniature  computer  and  a microprocessor. 

End-users  typically  Justify  microprocessors  on  the  basis  of 

. Small  size  (for  example,  one  must  Include  a controller 
in  an  actuator). 

. l.ow  cost  (for  example,  a more  expensive  classical  mini- 
computer or  large  amounts  of  slow,  special  purpose, 
logic,  would  otherwise  be  required). 

Note  that  while  size-related  special  packaging  considerations  are 
generally  valid,  cost  considerations  may  very  well  favor  classical  mini- 
computers, instead  of  microprocessors. 

Let  mo  show  an  example  (Figure  l).  Here  we  have  compared  the  unit  cost 
of  automating  a laboratory  instrument  using  either  a minicomputer  or  a micro- 
processor. As  the  curve  shows  we  have  found  that  you  must  build  at  least 
seven  identical  systems  before  microprocessors  start  to  have  an  edge  on  capital 
cost. 

When  we  also  compute  the  total  cost  of  ownership  including  spare  parts, 
maintenance  documentation,  maintenance  training,  etc.,  we  have  found  that, 
taking  the  technical  risks  into  account,  the  following  rule  of  thumb  holds: 
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Krom  the  total  cost  of  ownership  point  of  view  micro- 
processors should  not  be  used  for  process  control  unless : 

1.  You  need  at  least  100  Identical  (hardware/ 
software)  units. 

2.  Sources  ol  re-supply  (hardware/sof tware)  can  be 
provided  lor  about  18  years. 

J.  Long-term  maintenance  capability  is  assured. 

Th  i s clearly  very  caul  ions  posture  is  supported  not  only  by  cost 
cal eul at  ions,  but  also  bv  biller  experience.  In  fact,  it  seems  to  me 
that  microprocessors  ate  mnnut ac t ured  to  serve  the  fabricator's  con- 
venience not  that  ot  the  end-user.  Specifically: 

. Design  i>  simplified  to  the  extreme;  for  example, 

instrm  lions  wliiili  require  comp  1 ex  logic  are  seldom 
imp  I ement  ed . 

. Quality  assurance  is  minimized  to  hold  the  costs  down 
in  the  competitive  marketplace. 

. The  programming  tools  provided  with  microprocessors 
are  generally  primitive. 

Please  note  mine  Is  not  a lone  voice  in  l Ire  wilderness.  In  Toronto, 
during  Lite  International  Federal  loti  for  Information  Processing's  (IKIP) 
Congress  77,  I.  Barron  pointed  out  that  the  customary  8-blt  word  length  is 
"very  silly".  At  the  same  meeting,  K.  Dijksira  noted  that  "microprocessors 
are  not  great"  and  in  I art  are  "very  unreliable". 


However,  with  .ill  llieir  arelilleeliir.il  ami  quality  control  proh  I ems , 
mic ropressors  represent  a step  forward  in  llic  art  of  hardware  manufaclur ing. 
Wlial  is  truly  remarkable  is  that  this  slop  forward  is  accompanied  by  a 
twenty-year  regression  in  programming  capability  and  very  few  people  seem 
to  take  notice. 

What  most  of  us  overlook  is  that  in  addition  to  the  art  of  hardware 
manufacturing,  programming  has  also  advanced  dramatically  over  the  last 
20  years.  The  programming  of  a process  which  would  have  cost  of  the  order 
of  $1,000,000  in  the  late  1950's,  cost  about  $200,000  in  the  middle 
60's,  and  as  little  as  $10,000  now  in  the  late  70's. 

In  other  words,  the  cost  of  control  programming  declined  by  about 
two  orders-of-magnitude  in  the  last  20  years,  primarily  due  to  the 
evolution  of  advanced  programming  tools.  1 remember  when,  in  the  day 
of  million  dollar  programming  jobs,  end-user  management  insisted  on 
machine  language  programming,  since  computers  were  too  valuable  to  waste 
their  time  on  foolishness  such  as  FORTRAN.  Of  course,  time  proved  them 
wrong. 

Today,  we  hear  promoters  of  microprocessors  argue  that  end-users  should 
program  in  machine  language  since  microprocessors  are  cheap.  Presumably, 
cheap  computers  are  what  the  "market"  wants  and  micropressors  are  cheap 


not  only  because  their  design  is  simplified  and  quality  assurance  mini- 
mized, but  also  because  their  programming  tools  are  primitive.  Hence  the 
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regression  to  the  computing  methods  of  a quarter  century  ago  and  the 
introduction  of  our  break-even  rule  that  mic ropressors  should  not  be  used 
unless  at  least  a hundred  identical  units  are  required. 

The  apparent  marketing  strategy  of  "low  price  at  any  price"  may  be  caused 
by  the  microprocessor  manufacturers'  generally  valid  perception  of  their 
customers  as  computer  hobbyists.  A hobbyist  wants  to  eliminate  the 
expensive  middleman,  the  programmer;  considers  keyboarding  the  key  skill  of 
programming;  and  equates  the  art  of  programming  with  telling  the  machine 
in  AO  simple  instructions  what  to  do. 

What  the  hobbyist  lails  to  realize  is  that  microprocessor  programming 
is  the  art  ol  completely  specifying  the  behavior  (including  error  states)  of 
a complex  automaton  with  a vocabulary  of  AO  words  or  less  — an  expensive 
hobby  which  frequently  frustrates  even  experienced  professionals. 

Do  not  misunderstand:  My  thesis  is  not  that  end-users  should  not  do 
computer  programming.  They  should,  given  the  right  equipment  instead  of 
today 's  microprocessors. 

In  closing,  let  me  share  with  you  my  conjectures  as  to  what  is  really 
requ i red : 

. Firmware/hardware  operating  systems 

Most  systems  computers  require  basic  software,  usually  called 
the  "operating  system",  to  make  them  work.  While  this  arrangement 
is  satisfactory  lor  large  KDI’  systems,  integration  of  user 


programs  with  small  computer  operating  systems  is  quite  dil  limit 
and  expensive.  Therefore,  soil  ware  operal  lug  systems  should  go. 

A transitory  step  in  this  direction  could  replace  them  with 
firmware  equivalents,  followed  by  a fundamental  rethinking  of 
small  computer  architecture,  leading  to  an  end-user  oriented  genera- 
tion of  hardware  not  requiring  operating  systems  at  all. 

Multi-engine  Arithmetic  Machines 

Current  computers  are  Single-engine  Arithmetic  Machines:  t hey 
can  do  only  one  thing  at  a time.  Historically,  considerable  effort 
was  spent  on  operating  systems  which  "timeshare"  or  "multi-program" 
process  computers,  i.e.  make  them  appear  as  it  working  on 
several  subtasks  simultaneously  and  independently.  More  recently, 
the  "distributed  system"  idea  came  into  vogue  where  t he  subtasks 
of  running  a process  are  performed  by  interconnected  computers. 

Either  of  these  alternatives  imply  the  need  for  the  Multi-engine 
Arithmetic  Machine,  possibly  Implemented  as  a network  of  miniature 
computers,  each  of  which  was  designed  to  be  a low-cost  network 
element  capable  of  performing  simple,  specialized  subtasks. 

Superspeed  computers 

I know  some  end-users  who  would  get  ecstatic  if  they  could  simply  com- 
pute trajectories  of  large  chemical  processes  and  optimize  them  in 
real-time  using  advanced  linear  programming  methods.  To  do  this,  one 
would  probably  need  a hypothetical  super  computer  capable  of  speeds 


of  around  10-100  HPS  ^ ^ - people  or  micros  Just  would  not  do 
as  shown  In  Figure  2. 

Of  course,  to  work  with  operating  system-free  superspeed  Multi- 
engine  Arithmetic  Machines  we  end-users  will  need  superb  programming 
tools,  including  perhaps  new  problem-oriented  languages  and  a fresh 
approach  to  de-bugging. 


A Horner  is  about  one  million  calculations,  i.e.  a mix  of  additions 
subtractions,  multiplications,  and  divisions.  Therefore,  Horner/ 
second,  or  HPS,  is  about  one  millions  calculations  per  second.  On 
this  subject,  start  with  the  chapter  on  "Superspeed  Computers"  of 
"Future  Facts" 


by  Stephen  Rosen  (Simon  it  Shuster,  New  York),  p.  47. 
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FIGURK  2 


COMPAR 1 SON  OF  COMPUTING  SPKKDS 


Human  hi- In^s  will)  hand  calculators 


10" 7 11PS 


Kx Is ling  micros 


Bipolar  logic  computers 


- 10  11  PS 


Hypothetical  super  computer 
(possibly  using  Josephson  Cate  logic) 


100  IIPS 
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1.  STANDARDIZATION  EFFORTS 


IN  WEST  GERMANY  IN  THE 


FIELD  OF  SAFETY/  RELIABILITY 


AND  SECURITY 


2.  DEFINITION  AND  COMPUTATION 


OF  THE  SAFETY  OF  AUTOMATIC 


CONTROL  SYYTEMS 


« 1 
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STANDARDIZATION  INSTITUTIONS 


- AUTHORIZED  FOR  STANDARDISATION: 

GERMAN  INSTITUT  FOR  STANDARDIZATION  (DIN) 

- ACTIVE  FOR  STANDARD-PROPOSALS 
ABOUT  10  DIFFERENT  COMMITTEES 

1 

IN  THE  FIELD  OF  SAFETY 

WITHIN  THE  ASSOCIATION  OF  GERMAN 
ENGINEERS  (VDI/VDE) 

- FOR  COORDINATION  OF  ALL  EFFORTS 
IN  THE  FIELD  OF  SAFETY  TERMS 
COMMITTEE:  SAFETY  TERMS  (A  1.7) 

PROPOSED  BY  PROF.  LAUBER 
WILL  BE  FOUNDED  ON  OCTOBER  21,  1977 


COOPERATION  WITH 
INTERNATIONAL  ORGANIZATIONS 


PURDUE  EUROPE  TC  7 
SAFETY  AND  SECURITY 


32  MEMBERS  . 

17  CORRESPONDING  MEMBERS 


TERMS  AND  DEFINITIONS 
PROJECT  MANAGEMENT 
SOFTWARE 
HARDWARE 


DOCUMENTATION 


PE  / TC  7 ACTIVITIES 


- OVER  100  WORKING  PAPERS 

- SOME  WP  ARE  ALREADY  PUBLISHED 

- GUIDELINES  FOR  THE  DESIGN 
OF  SAFETY  RELATED  SOFTWARE 
ARE  ACCOMPLISHED 

- GUIDELINES  FOR  THE  DOCUMENTATION 
OF  SAFETY  RELATED 

COMPLEX  SYSTEMS  WILL  BE 
WORKED  OUT 

- WP  CONCERNING  POSSIBILITIES 
IN  THE  DESIGN  OF  SAFE 
COMPUTER  SYSTEM  HARDWARE 
WILL  BE  COMPLETED 

- PANEL  DISCUSSION  IN  THE  FIELD 
OF  SAFETY  IS  SCHEDULED  ON  THE 

I FAC  - CONGRESS  IN  HELSINKI  / FINLAND 
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f UR  1 1 IL  K AC1 IV  HIES 
IN  Tilt  FIELD  OF  SAI  LIY 


I NS  1 1 1 U I IONS  SPONSORED 
THESE  ACTIVITIES: 

- RESEARCH  PROMOTION 
INSTITUTION  FOR  PROCESS  CONTROl 
(PDV) 

- GERMAN  RESEARCH  FOUNDATION 
(DFG) 

- GERMAN  FEDERAL  RAILWAYS 
(03) 

- COMPANIES 

- UNIVERSITIES 


W 


DEFINITION  AND  COMPUTATION 
OF  THE  SAFETY  OF  AUTOMATIC 
CONTROL  SYSTEMS 


LITERATURE: 

KONAKOVSKY,  R. : DEFINITION  UND 
BERECHNUN6  DER  SICHERHEIT  VON 
AUTOMAT  IS  I ERUNGSSYSTEMEN. 
DISSERTATION/  UNI  STUTTGART, 

VIEWEG  & SOHN,  BRAUNSCHWEIG  OKT.  1977 


THIS  WORK  WAS  SPONSORED  BY 
GERMAN  RESEARCH  COMMUNITY  (DFG) 


1 1 - ■-  ".rr-'\  1 — ^ 
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SOME  KINDS  OF  SAFETY  / SAFENESS: 

- FAIL-SAFE 

- SAFETY  OF  OPERATION 

- SAFETY  IN  TRAFFIC  / FLYING 

- REACTOR  SAFETY 


COMMON  FEATURE: 

THE  OCCURRENCE  OF  PARTICULARLY 
UNDESIRABLE  EVENTS  HAVE  TO  BE  EXCLUDED 


FOR  ABOVE  KINDS  OF  SAFETY: 

- DANGEROUS  FAILURE  (-EFFECT) 

- DANGEROUS  OPERATION  STATE 

- TRAFFIC  /AVIATION  ACCIDENT 

- DAMAGES  TO  REACTOR  THROUGH  EXPLOSION 


FOR  ALL  SUCH  EVENTS 
THE  COMMON  TERM 


INADMISSIBLE  EVENTS 


WILL  BE  USED  IN  THE  NEXT 


sequence  of  events  observable 

IN  A SYSTEM  WHERE  AN  ACCIDENT 
OCCURES 


FAULT-FREE  CONTROL  SYSTEM 
COMPONENT  FAILURE 

FUNCTION  CHANGE  OF  THE  CONTROL  SYSTEM 

INADMISSIBLE  FUNCTION  CHANGE 

INADMISSIBLE  CONTROL  SIGNAL 

INADMISSIBLE  PROCESS  STATE 

INADMISSIBLE  PROCESS  EVENT 
(ACCIDENT) 

INADMISSIBLE  CONSEQUENCES 
(DAMAGES) 


*****  1111 JMfll  i - jt. s»  -aYI*  — « £.  * . •*■ 

« 
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I LLUSTRAT I VE  EXAMPLE 


LOGIC  FUNCTION  OF  A UNIT  OF  THE 
CONTROL  SYSTEM  AND  ITS  CHANGE 
THROUGH  A COMPONENT  FAILURE  : 


U1 

U2 

Y 

A 

Y 

0 

0 

0 

0 

0 

L 

0 

L 

L 

0 

0 

0 

L 

L 

L 

L 

Up  U2  INPUT  VARIABLES 

Y OUTPUT  VARIABLE 

Y OUTPUT  VARIABLE  IN  THE 

CASE  OF  A FAILURE 

CRITERIUM  FOR  ADMISSIBILITY  : 

Y - Y 
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DEFINITION  OF  SAFETY 


SAFETY  IS  THE  ABILITY  OF  A SYSTEM 
(ITEM)  TO  AVOID  THE  OCCURRENCE  OF 

INADMISSIBLE  EVENTS 

UNDER  STATED  CONDITIONS  FOR 
A STATED  PERIOD  OF  TIME 


BECAUSE  THERE  ARE  FIVE  TYPES  OF 
INADMISSIBLE  EVENTS  (©  TO  ©) 
THERE  ARE  FIVE  TYPES  OF 
SAFETY,  FOR  EXAMPLE: 

SAFETY  WITH  REGARD  TO  NON- 
OCCURRENCE OF  INADMISSIBLE 
CONTROL  SIGNAL  (EVENT  ©) 


FOR  EVENTS  © TO  © THE 
TERM  "DANGEROUS"  CAN  BE  USED  TOO/ 
E.G. : DANGEROUS  CONTROL  SIGNAL 
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COMPUTATION  METHOD 


FROM  THE  ABOVE  SAFETY  DEFINITION 
SOME  FIGURES  OF  MERIT  CAN 
BE  DERIVED,  FOR  EXAMPLE: 

MTDF  MEAN  TIME  TO  DANGEROUS  FUNCTION 
MTDS  MEAN  TIME  TO  DANGEROUS  SIGNAL 


FOR  COMPUTING  MTDF  / MTDS  A 
SO  CALLED  FAILURE-EFFECT-DIAGRAM 
HAS  TO  BE  BUILT 

PROVIDED  ALL  TRANSITION  RATES 
ARE  CONSTANT,  MTDF  / MTDS  CAN 
BE  OBTAINED  BY  APPLYING  THE 
METHOD  OF  MARKOV  CHAINS  TO 
THIS  DIAGRAM 
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FAILURE  - EFFECT  - DIAGRAM 


FOR  SINGLE  AND  DOUi LE  FAILURES 


o V- 


V > 

K**\ 


NT  K 


V \ 


NT  \ 


I 


FIRST 

FAILURE 


SECOND 

FAILURE 

+ 

SECURING 


FAULT  - FREE  FUNCTION 
DANGEROUS  FUNCTION 
SAFE  FUNCTION 
FUNCTION  NOT  YET  CHANGED 


MEAN  TIME  TO  DANGEROUS  FUNCTION 


1 + 


Zi  e NT 


X * 


Z,  o NT 


_ 


i 


CONCLUSION 


- STANDARDIZATION  IN  THE  FIELD 

OF  SAFETY  IS  POSSIBLE  IN  A FORM 
INDEPENDENT  OF  THE  APPLICATIONS 
SUCH  AS  RAILWAY  SYSTEM, 

CHEMICAL  OR  NUCLEAR  REACTOR 
SYSTEMS 

- STANDARDIZATION  EFFORTS  IN 
WEST  GERMANY  WILL  SURELY 
HELP  TO  SOLVE  THE  DISCUSSED 
PROBLEMS 


-AA5- 


APPENDIX  TV 


IRM  SERIES/ 1 PL/1 


A Tutorial  by 

Alex  J.  Arthur 
IRM  Corporation 
San  Jose,  California 


f 


— ^ :^LLr.\.\w ‘"L' T 1 ™':  " "■■.v-rrm. 
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SERIFS/1  PL/I 
IS 

- A SUBSET  OF  ANSI  X3.53  - 1976 

PLUS 


IBM  EXTENSIONS 
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I 

Pi  REFERENCES 

- 

1)  IBM  SERIES/1  PL/I  INTRODUCTION, 

GC34  - 0084  - 0, 

FEBRUARY  1977 

2)  IBM  SERIES/1  PL/I:  LANGUAGE  REFERENCE 
GC  34  - 0085  - 0 
AUGUST  1977 

3)  AMERICAN  NATIONAL  STANDARD 
PROGRAMMING  LANGUAGE  PL/I, 

ANSI  X3.53  - 1976 


AJA 

77.09,30 


f 


r 
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SUBSET  CONTENT 


ATTRIBUTES 

STATEMENTS  AND  OPTIONS 

CONDITIONS 

BUILT-IN  FUNCTIONS 
AND 

PSEUDO -VARIABLES 

CONSTRAINTS 


AJA 

77,06,16 
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ATTRIBUTES 

ALIGNED/UNALIGNED 

POINTER 

AUTOMATIC/STATIC/BASED 

PRINT 

BINARY/DECIMAL/precision 

RECORD/STREAM 

BIT/CHARACTER/length 

RETURNS 

BUILTIN 

VARYING 

CONDITION 

dimension/member/structure 

DIRECT/SEQUENTIAL 

ENTRY 

ENVIRONMENT 

EXTERNAL/INTERNAL 

FILE 

FIXED/FLOAT 

FORMAT 

INITIAL 

INPUT/OUTPUT/UPDATE 

KEYED 

LABEL 

PARAMETER 

AJA 

77,06, 18 
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STATEMENTS  AND  OPTIONS 

Assignment,  element 
array 

STRUCTURE 

BEGIN 

OPTIONS 

CALL 

CLOSE 

DECLARE 

DELETE 

DO  - ITERATIVE 

WHILE 

END 

FORMAT 
GET  LIST 
EDIT 
STRING 

EXPRESSIONS 

DO 

SKIP 

LINE 

PAGE 

GOTO 

IF 

NULL 

ON  SYSTEM 
OPEN 

PROCEDURE 
OPTIONS 
RECURSIVE 
RETURNS 
PUT  see  GET 


READ 


RETURN 

REVERT 

REWRITE 


SIGNAL 

STOP 

WRITE 


INTO 

IGNORE 

KEY 

KEYTO 


FROM 

KEY 

EVENT 


FROM 

KEYFROM 


AJA 

77,06,16 
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CONDITIONS 


CONDITION 

CONVERSION 

ENDFILE 

ENDPAGE 

ERROR 

FINISH 

FIXEDOVERFLOW 

KEY 

OVERFLOW 

RECORD 

SIZE 

STRINGRANGE 

STRINGSIZE 

SUBSCRIPTRANGE 

TRANSMIT 

UNDEFINEDFILE 

UNDERFLOW 

ZERODIVIDE 


AJA 

77.06.16 


i 


BIT,  BOOL,  CHAR,  COPY,  HIGH,  LENGTH,  LOW,  SUBSTR  & 

PV,  UNSPEC  & PV 

ARITHMETIC 

ABS,  BINARY,  DECIMAL,  FIXED,  FLOAT,  PRECISION,  SIGN 
MATHEMATICAL 

ACOS,  ASIN,  ATAN,  ATAND,  COS,  COSD,  EXP,  LOG,  L0G2, 

LOGIO,  SIN,  SIND,  SORT,  TAN,  TAND 

ARRAY  HANDLING 

DIM,  EVERY,  HBOUND,  LBOUND,  SOME 
CONDITION  - HANDLING 

ONCHAR  & PV,  ONCODE,  ONFILE,  ON KEY,  ONLOC,  ONSOURCE  & PV 
STORAGE  CONTROL 

ADDR,  NULL 
MISCELLANEOUS 

DATE,  TIME,  LINENO  AJA 
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CONSTRAINTS 


Precision 

Fixed  binary 

p s 31,  q=0 

Decimal 

Pi  15,  -128  -q  -+  127 

Float  binary 

p- 53 

DECIMAL 

ps  16 

2)  No  ADJUSTABLE  STRING  LENGTHS  OR  ARRAY  EXTENTS  IN 

AUTOMATIC,  dimension,  BASED 

3)  No  REFER  option  in  BASED 

4)  String  lengths  255  bits  or  characters 

5)  No  INITIAL  for  AUTOMATIC 

6)  Parameter  string  lengths  and  extents  of  arrays 
OF  structures  must  be  constants,  simple  array 

CAN  HAVE  * 

7)  Arithmetic  data  must  be  ALIGNED 

8)  Structure  assignment  only  for  like  attributes 

9)  Only  simple  scalar  expressions  allowed  as  CALL 

ARGUMENTS 

10)  Remote  FORMATS  must  be  in  same  block 


AJA 

77,06.16 


ATTRIBUTES 


ACTIVATION 

AFTER 

AT 

CONNECTED 

EVENT 

LOCK 

PROGRAM 

SOURCE 

TRANSIENT 


AJA 

77.06.16 


"’TipT*' 


' 
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STATEMENTS 

CLEAR/POST 

DELAY 

CONNECT/DISCONNECT 

DISPLAY 

LOCK/UNLOCK 

MAIN 

STACKS IZE 
TASK 
REPEATS 

ENVIRONMENT  on  FILE  DCL  ) 
RUN 

STOP  TASK 

ACTIVATION 

TRANSFER  TO 
WAIT 


PROCEDURE  OPTIONS 


READ/WRITE/REWRITE  EVENT 
READ/WRITE  sensor  I/O  ( requires 


UNSCHEDULE 


AJA 

77,06.16 


*"**•*'  . 
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CONDITIONS 


PENDIN6 


77.06.16 


COUNT 


DAVNO 


ONCOUNT 


PRIORITY 


STATUS  & PSV 


AJA 

77.06.16 


1 


EXAMPLES 


AJA 

77,06,16 
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DCL  (Tl,  T2)  ENTRY  EXTERNAL, 

(Al,  A2)  ACTIVATION  EXTERNAL, 

(El,  E2)  EVENT  EXTERNAL, 

(PI,  P2)  PROGRAM, 

1(2),  J(2); 

RUN  T1  ACTIVATION  (Al), 

EVENT  (El), 

PRIORITY  (I), 

AT  ('1215'); 

RUN  T2  EVENT  (E2), 

AFTER  (200); 

RUN  PI  ACTIVATION  (A2), 

EVERY  (2000); 

RUN  P2  PRIORITY  (J), 

SOURCE  ENVIRONMENT  (DEVNBR(4),  P1BIT  (6)); 


WAIT  (El,  E2 ) ( 1 ) ; /*Wai r for  either  task  T1  or  T2  to  complete*/ 


UNSCHEDULE  ACTIVATION  (A2);  /’Eliminate  schedule  for  program  PI*/ 
STOP  ACTIVATION  ( A2 ) ; /*Stop  it  if  it  is  in  execution*/ 


J 
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DCL  (LI,  L2)  LOCK  EXTERNAL, 

(El,  E2)  EVENT  EXTERNAL, 

E3  EVENT  EXTERNAL 

SOURCE  ENVIRONMENT  (DEVNBR  (A),  PIBIT  (7)), 
P3  PROGRAM; 


LOCK  (LI); 

CONNECT  (E3); 

LOCK  (L2)  ELSE  BEGIN: 

UNLOCK  (LI); 
CLEAR  (El); 

POST  (E2); 
DISCONNECT  (E3); 
TRANSFER  TO  P3; 
END; 

i 

UNLOCK  ALL; 
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DECLARE  PCNTRL  ENTRY, 

BATCH  ENTRY, 

PC  ACTIVATION  EXTERNAL, 

B ACTIVATION  EXTERNAL, 

El  EVENT  EXTERNAL, 

DAYBEG  EVENT  EXTERNAL  AT  ('0800'), 

DAYEND  EVENT  EXTERNAL  AT  ('1730'); 

CTLLOOP: 

WAIT  (DAYBEG);  /*  Wait  until  8:00  A.M.*/ 

CLEAR  (DAYBEG);  /*  Reset  event  variable*/ 

RUN  PCNTRL  ACTIVATION  (PC) 

EVENT  (El);  /*  Start  process  control*/ 


* 


WAIT  (DAYEND, El)(l);  /* 

STOP  ACTIVATION  (PC);  /* 

WAIT  (DAYEND);  /* 

CLEAR  (DAYEND);  /* 

RUN  BATCH  ACTIVATION  (B) 

EVENT  (E2);  /* 

WAIT  (DAYBEG, E2)  (1);  /* 

STOP  ACTIVATION  (B);  /* 

GO  TO  CTLLOOP;  /* 


Wait  until  either  5:30  P.M.  or 
process  control  finishes*/ 

Stop  process  control  if  still 

ACTIVE*/ 

Wait  until  5:30  P.M.  unless 

THAT  TIME  HAS  ALREADY  PASSED*/ 

Reset  event  variable*/ 

Start  batch*/ 

Wait  until  either  8:00  A.M. 
or  batch  finishes*/ 

Stop  batch*/ 

Start  morning  task*/ 
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APPENDIX  V 


APL  AS  A REAL-TIME  LANGUAGE 


A Tutorial  by 
Janos  Gertler 

Case-Western  Reserve  University 
Cleveland,  Ohio 


"The  reported  work  was  done  at  the  Chemical  Engineering 
Department  of  Case  Western  Reserve  University,  Cleveland, 
Ohio,  with  the  participation  of  Dr.  Adin  J.  Mann  and  Dr. 
Robert  V.  Edwards  under  research  grants  from  NIH  (General 
Medical)  and  ERDA." 


APL  AS  A REAL-TIME  LANGUAGE 


WHY  APL? 

IT  IS  NOT  A REAL-TIME  LANGUAGE  BUT 

- IT  IS  INTELLIGENT  (EXCELLENT  ARRAY  HANDLING  FEATURES) 

- IT  IS  INTERACTIVE 

- EXPERIMENTING  PEOPLE  (PHYSICISTS,  CHEMIST)  USE  IT  TO 
EVALUATE  EXPERIMENTAL  RESULTS:  EVALUATION  AND  EXPERI- 
MENTATION IS  DONE  IN  THE  SAME  SYSTEM. 
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SOME  APL  FEATURES 

- LARGE  SET  OF  CHARACTERS 

- LARGE  SET  OF  PRIMITIVE  FUNCTIONS  AND  OPERATORS, 
MOST  DEFINED  ARRAYS 

- SYSTEM  VARIABLES  AND  SYSTEM  FUNCTIONS  (□) 

- USER  DEFINED  FUNCTIONS 

V NAME;  VARIABLES 


V 


- SHARED  VARIABLES  FOR  DATA  INTERCHANGE 
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REAL-TIME  EXTENSIONS 

NO  BRAND  NEW  IDEA. 

SOURCES: 

- LTPL  CANDIDATE  LANGUAGES 

- AN  EARLY  ALGOL  EXTENSION 

EXTENSION  AREAS: 

1.  PROCESS  I/O  AND  SYSTEM  DEFINITION 

2.  TASKING 

5.  INTER-TASK  COMMUNICATION 
HAS  TO  BE  CONSISTENT  WITH  THE  REST  OF  THE  LANGUAGE: 

1.  SYSTEM  VARIABLES  AND  FUNCTION  DEFINITION 

2.  SYSTEM  FUNCTIONS 

3.  SHARED  VARIABLES 


i 


PROCESS  I/O 


SYMBOLIC  NAMES  AS  SPECIAL  VARIABLES 

PROCESS  INPUT:  0 TEMPO 
PROCESS  OUTPUT:  0 VALVE3 
EXTERNAL  EVENT:  [0  SWITCH] 

PROCESS  INPUT  AM)  OUTPUT  VARIABLES  ARE  USED  IN  PROGRAMS 
AS  ORDINARY  VARIABLES. 

RESTRICTIONS: 

- NO  VALUE  ASSIGNMENT  TO  AN  INPUT 

- ONLY  VALUE  ASSIGNMENT  TO  AN  OUTPUT 

EXAMPLES: 

Y«— 3 + Kx  0 TEMP6 
0 VALVE3< 1 

0 VALVES  « 0 TEMPO  > TL6 

0 VALVE  « 0 TEMP  > TL 


I/O  OPERATION  IMPLICIT 


DEFINITION  OF  I/O  VARIABLES 


ELEMENTS: 


- SYMBOLIC  NAME  E.6.  a TEMPO-  0 VALVE  3 

- HARDWARE  ADDRESS  E.G.  AM3  [9]  - OM'I  [6] 

- HARDWARE-LEVEL  FUNCTION  E.G.  Q|II3,  □ HON 


- HARDWARE  ADDRESS 


- SOFTWARE-LEVEL  FUNCTION  E.G.  CONV,  REV 


FORMAT:  LIKE  FUNCTION  DEFINITION 


EXAMPLES 

V g TEMP6 

AM3  [9] 

V 

V 0 TEMPO 

0* □ HI3  AM3  [9] 

V 

V 0 TEMP6 

0« K + Cx  Q HI3  AM3  [9] 


r ^.ir _z  ;_  : . 
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V 0TEMP6 

0« PAR  CONV  QllIS  AM3  [9] 

i . V 

V 0 VALVE3 

OHA  [c]  « 0 

V 

V 0 VALVE3 

m 0— 0HOA  0 

V 

V0  VALVE3 

OMA  [c]« — 0HOA  K + Cx0 

V 

V 0 VALVE3 

OMA  GD«H  □ IIOA  PAR  REV  0 

V 


va  TEMP  [i6] 

0* Af13  [d  + it] 

V 

V 0 temp  [i6] 

0-* PAR  0]  CONV  0HI3  AH3  [s  + ic] 

V 


- - 


' 

« - - . » _ ito.. 
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TASKING 

A REASONABLE  SET  OF  TASKING  FACILITIES 

FORM:  SYSTEM  FUNCTIONS 

TASK  ACTIVATION 

PRIORITY  DtAN  TNAME 

CANCELLING  ACTIVATION 
□ TCA  TNAME 

SINGLE  SCHEDULE 

PRIORITY  DELAY  QtSS  TNAME 
REPEATED  SCHEDULE 

PRIORITY  INTERVAL  REPETITION  (DELAY)  QtSR 
TNAME 

PERIODIC  SCHEDULE 

PRIORITY  INTERVAL  (DELAY)  QtSP  TNAME 

CANCELLING  SCHEDULE 
D TCS  TNAME 

OBTAINING  SCHEDULE 
Q TDS  TNAME 
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DELAY  I N6 
DELAY 

SUSPENDING 

EVENT 


□ tdt 

□ tde 


TNAME 


TERMINATING 

□ TTE  TNAME 


DEFINING  A SEMAPHORE 

TOP  START  Q SEM  SNAME 

REQUEST 

□ SRQ  SNAME 
RELEASE 

QSRL  SNAME 


LINKING  A ROUTINE  TO  AN  EVENT 
EVENT  Q]  REL  RNAME 

CANCELLING  A LINK 


EVENT  □ RCL  RNAME 


r 


* ' 
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TASK  AND  ROUTINE  DEFINITION 

DIRECT  DEFINITION: 

ROUTINE  VV  RflAf'E;  VARIABLES 

BODY 

vv 

TASK  V V V TNAMEj  VARIABLES 

BODY 

V VV 

INDIRECT  DEFINITION: 

V NAME;  VARIABLES 

BODY 

V 

CODE  4 — 0CR  ' NAME ' 

□ EX  'NAME' 

CODE  QRD  RNAME 
CODE  0TD  TNAIE 
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THE  IMPACT  OF  NEW  TRENDS  IN  HARDWARE 
ON  COMPUTER  SYSTEMS  INTERFACES 


Mr . Anthony  Deramo 


freckoub  f tat  bujk 
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Dr.  Gt'llie  asked  that  I highlight  the  efforts  of  TC5  and  review  with  you 
the  functional  areas  where  there  is  potential  for  support  from  other 
technical  groups  within  the  Workshop. 


Industrial  Process  Computer  Inter-Subsystem  Communication  has  been  the 
primary  concern  of  TC5  for  the  past  two  years  and  the  conmitee  has  derived 
a functional  requirements  document  against  which  existing  and  proposed 
communication  subsystems  can  be  evaluated.  The  discussions  have  been  long 
and  not  without  emotion.  To  some,  many  of  the  discussions  have  been  redundant. 
To  the  impatient,  TC5  should  have  settled  on  a standard  by  this  time  based  on 
available  methods  and  technology.  To  others,  it  has  been  important  to  lay 
some  basic  groundwork  which  may  have  a converging  influence  on  the  various 
approaches  to  process  computer  communications  in  the  future. 


I personally  have  difficulty  in  extracting  from  the  functional  requirements 
document,  a practical  subset  for  each  process  communication  requirement  that 
we  now  have. 

I have  selected  a few  examples  from  existing  programs  within  Westinghouse 
to  further  illustrate  this. 


The  first  is  a new  microcomputer  based  product.  In  the  memory  of  this  unit 
is  process  data  in  digital  form  that  is  required  or  could  be  used  by  other 
control  systems. 


Second,  is  a new  line  of  functional  modules  for  use  in  distributed  control 
systems.  This  type  of  system  offers  the  opportunity  to  extend  and  distri- 
bute the  digital  base  making  it  more  flexible  than  was  formerly  possible. 

Also  distributing  the  data  presents  a different  set  of  coordination  require- 
ments than  formerly  was  necessary. 

i 1 

The  third  example  deals  with  the  conventional  process  computer  system  and 
the  impact  of  LSI  on  this  architecture. 


The  energy  crunch,  environmental  pressures,  and  the  need  to  make  a profit 
require  that  more  sophisticated  levels  of  control  be  added.  These  levels 
in  the  form  of  conventional  computers  connected  in  a computer  hierarchy 
will  require  access  to  the  available  data  base. 


jfOCIBMO  PAfl*  BLAME 


It  is  a t this  level  that  the  great  rajority  of  TC5  decisions  do  involve 
future  trends  in  software  methods  and  there  is  a need  to  factor  tnis 
thinking  into  our  decision  making  process. 

Now!  the  first  example. 

We  recently  concluded  the  design  and  development  of  an  electronics  packaoe 
for  our  insitu  02  sensor.  This  was  done  to  support  polution  monitor 
applications,  where  the  EPA  requires  that  the  sensor  calibration  be  checked 
and  recorded  daily. 

We  incorporated  a microcomputer  in  the  package  to  provide  a convenient  means 
to  record  calibration  data. 

The  implementation  was  simple  and  straight  forward  because  we  knew  exactly 
what  had  to  be  done  to  gain  wide  spread  acceptance  for  the  product.  We 
structured  the  log  format,  listed  the  data  in  ASCII  form  and  provided  an 
RS232C  port. 

With  the  flexibility  of  the  microcomputer,  we  were  able  to  add  a self- 
calibrating option,  and  several  process  controller  options.  The  control 
options  support  several  applications  ranging  from  damper  position  control 
to  fuel  or  air  trim  control  based  on  excess  02  in  a boiler  control  system. 

When  doing  air  trim  control  for  a boiler,  the  unit  has  most  of  the  process 
data  in  digital  form  that  is  required  to  calculate  boiler  efficiency. 

Plant  load  balance  based  on  boiler  efficiency  is  beyond  the  capability  of 
this  unit  but  an  additional  serial  communication  port  was  added  to  the  unit 
to  provide  access  to  this  process  data. 

The  implementation  for  this  port  was  not  simple  and  anything  but  straight, 
forward  because  we  did  not  know  what  had  to  be  done  to  gain  product 
acceptance.  No  standard  exists  for  serial  process  data  communication  of 
this  type. 

This  is  obviously  a case  where  those  impatient  with  TC5  results  to  date 
are  right.  Base  on  available  methods  and  technology,  one  of  several 
implementations  would  do,  so  long  as  there  was  a general  acceptance  to  the 
selected  approach. 
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New  microprocessor-based  control  system  module'.  culled  i)-tine  h.iv>*  been 
developed  b/  Westinghouse  for  use  by  their  system  engineers  in  distributed 
control  systems  applied  to  a broad  range  of  process  control  applications. 

Desioned  into  the  Q-line  architecture  are  several  conreuni cat  ion  options. 

There  is  a renotable  share  nemory  nodule  which  provides  the  means  to  establish 
100!  redundancy  for  the  microprocessor-base  control  modules  and  to  provide 
hign  speed  data  transfers  required  for  control  coordination  between  unit 
control lers . 

There  is  a simplex  communication  link  nodule  which  provides  a read  only  access 
for  process  data  when  the  control  system  is  applied  in  a safety  and  protect 

application. 

There  a half-duplex  supervisory-type  link  module  for  the  more  general 
process  control  application.  (By  supervisory  type  I mean  32  bit  fixed 
format  which  includes  start,  and  stop  framing  bits  and  a 5 bit  Boise 
Churdi  Erroring  code.) 

There  are  more  options,  but  point  is  made,  i.e.  Communication  requirements 
for  distributed  microprocessor-based  control  systems  of  this  type  are 
sensitive  to  application  and  the  individual  suppliers  architecture. 

It  would  be  very  difficult  for  TC5  to  select  one  supplier's  method  and 
gain  general  acceptance  to  the  selected  approach. 

The  majority  of  process  control  computers  are  single  computers  which 
provide  a multiprogramming  and  multitasking  environment  to  control  the 
concurrent  execution  of  a thousand  or  more  tasks. 

We  can  take  advantage  of  the  inexpensive  large  scale  integrated  circuits 
in  this  architecture  in  several  ways  without  disturbino  the  basic  appli- 
cation. 

First,  let's  replace  the  central  processing  unit  electronics  with  LSI 
being  careful  to  preserve  the  original  instruction  set  which  is  required 
if  we  are  not  going  to  disturb  the  basic  application. 
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What  is  gained? 

In  the  case  of  the  W25GO  process  comcuter,  a dramatic  reduction  in 
electronic  hardware. 

The  LSI  version  occupies  less  than  20  of  the  spare  required  by  the 
original  central  processing  unit. 

Less  energy  is  required  to  operate  the  unit. 

Performance  levels  are  generally  improved. 

Now  let's  add  programmable  LSI  to  selected  units  that  are  connected  to 
the  computer  bus.  This,  obviously,  leads  to  distributed  processing 
Process  I/O  scans  which  previously  required  central  comouter  core  memory 
to  store  the  scan  application  programs  and  central  processor  time  to 
perform  the  actual  scans  can  now  be  done  in  the  process  I/O  unit.  The 
data  is  passed  on  to  the  central  data  base  on  a CPU  cycle  steal  basis 
through  the  direct  memory  access  bus.  Distributed  processing  has  been 
especially  highlighted  in  the  serial  communi cati on  interface  area  with 
announcements  by  several  semiconductor  firms  of  LSI  multiprotocol 
communication  chips.  (Signetics  and  SMC-Standard  Microsystems  Corp). 

These  chips  have  computer-addressable  protocols  that  enable  them,  by 
computer  command  to  handle  IBM  SDLC;  B I SYNC;  DEC'S  DDCMP,  ADCCP  and  in 
the  case  of  the  SMC  chip,  HDLC.  These  chips  do  not,  however,  completely 
eliminate  the  software  needed  for  communication  and  they  do  not  perform 
any  of  the  hardware  functions  required  to  establish  the  point  to  point 
communication  channel. 

What  does  this  all  mean  from  an  application  point  of  view?  Well,  it  means; 

1.  More  available  processor  time, 

2.  More  available  core  memory  space, 

3.  Less  cost, 

4.  Improved  MTTR, 

5.  Greater  communication  flexibility,  and 

6.  Higher  performance. 

for  the  conventional  single  computer  system. 

In  contrast  to  this  type  of  system,  a variety  of  CPU's  are  available  on 
a single  chip.  Add  a little  memory,  process  I/O,  and  a serial  communica- 
tion interface  and  essentially  we  have  a similar  architecture  to  the 
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conventional  single  computer  system  but  with  a much  lower  pert  v ance 
level.  Tnis  type  of  structure  is  also  effective  at  the  sensor  product 
and  process  controller  level  to  provide  added  control  flexibility. 

Lets  look  at  some  of  the  areas  where  future  trends  in  software  rethods 
could  effect  TC5  efforts. 

I have  shown  several  computers  tied  together  throuah  a process  inter- 
computer subsystem.  Depending  on  your  own  personal  perspective,  the 
process  computers  may  be  microcomputers  or  conventional  computers. 

Paragraph  4.0  of  the  TC5  Functional  Requirements  document  deals  with 
ARCHITECTURE.  I quote; 

"4.1  The  communication  subsystem  shall  be  capable  of 
supporting  centralized  intelligence,  distributed 
intelligence,  hierarchical  intelligence  and  com- 
binations thereof.  In  particular,  it  shall  be 
capable  of  supporting  distributed  systems  for 
process  measurement  and  control." 

"4.2  The  available  architectures  of  the  communications 

subsystem  should  not  preclude  direct  data  interchange 
between  any  two  subsystems:  it  should  be  possible  to 
transmit  data  directly  between  any  two  subsystems  on 
the  link  without  necessarily  involving  store  and  for- 
ward at  a third  subsystem." 

The  hardware  required  to  establish  reliable  distributed  mastership  is 
not  a trivial  matter  but  lets  forget  it  in  favor  of  possible  software 
ramafi cations. 

The  Data  Base  manager  in  this  representation  as  part  of  its  function 
has  responsibility  to  provide  access  to  the  communication  system  and 
to  establish  access  through  the  communication  system  to  other  data 
bases  in  the  system.  Normally  it  is  designed  to  provide  access  or  to 
limit  access  only  after  specific  security  criteria  has  been  satisfied. 
In  the  hierarchy  shown,  a process  data  manager  would  have  no  need  to 
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access  the  energy  management  data  base.  If  it  did,  the  energy  management 
unit  would  not  respond. 

On  the  other  hand,  any  of  the  higher  level  computer  systems  may  need  to 
access  the  unit  process  data  base  and  the  security  overhead  is  not 
required.  The  establish  access  function  is  required  in  the  process  unit 
only  for  access  to  the  other  process  unit  data  base.  The  process  to 
process  access  requirement  is  debatable. 

If  it  is  required,  then  distributed  mastership  is  required  to  eliminate 
store  and  forward  operations  at  the  unit  process  level. 

If  it  is  not- required , then  distributed  mastership  is  not  required  at  the 
unit  process  level . 

Past  experience  with  the  conventional  single  computer  system  is  that 
coordination  for  basic  control  between  two  unit  processes  is  minimum. 

If  required  the  signals  needed  would  be  wired  to  both  computers. 

There  are  both  software  and  hardware  issues  involved  here. 

Software  methods  that  deal  with  rules  of  access  for  a distributed  data 
base  would  establish  appropriate  overheads  for; 

1.  providing  access  to  the  data  base 

2.  providing  security  access,  and 

3.  establishing  access  to  the  data  base. 

or  should  rules  of  access  be  incorporated  as  part  of  the  communication 
subsystem? 

In  dealing  with  conventional  computers,  this  is  still  a trade-off 
decision  between  hardware  and  software.  With  the  reduced  performance 
microcomputer  architecture,  there  is  probably  not  horsepower  available 
within  the  basic  unit  to  perform  these  tasks  so  it  might  be  advantageous 
to  incorporate  these  functions  as  part  of  the  communication  subsystem. 

Is  it  practical  to  consider  distributed  mastership  at  the  unit  process 
control  level? 
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Structure  of  the  distributed  data  base  is  another  area  which  could  impact 
communication  standard;. 

As  an  alternate  to  distributed  mastership  at  the  unit  process  level,  a 
"look  at  me"  indication,  would  provide  notification  to  the  higher  levels 
of  a change  in  configuration  and  initialization  data  permitting  it  to  be 
treated  on  an  exception  basis. 

In  some  distributed  computer  systems,  global  commands  and  global  peri- 
pherals are  featured  making  the  individual  operating  systems  act  as  one 
unified  system. 

Again,  this  is  certainly  within  the  performance  scope  of  the  conventional 
computer  system.  Within  the  reduced  performance  microcomputer  architecture, 
there  is  probably  not  the  requirement  or  the  capability  for  this  level  of 
performance. 

CONCLUSIONS 

TC5  has  as  an  immediate  objective  the  recommendation  of  a standard  for 
industrial  process  computer  inter-subsystem  communication.  To  do  this, 
we  must  make  sound,  practical,  technical  judgements  concerning  the  process 
environment  and  the  communication  requirements.  There  are  many  more  bases 
to  cover  if  we  are  to  succeed. 

As  a practical  alternate  to  an  immediate  standard,  I suggest  we  explore  in 
cooperation  with  other  technical  committees  within  the  Purdue  Workshop 
meaningful  levels  of  interface  for  computers,  measurement  and  control  sub- 
systems which  contain  computers  connected  together  by  a serial  communica- 
tion subsystem  so  that  a 

standard  interconnection  method  can  become  a reality. 

What  we  are  now  able  to  do  because  of  LSI  technology  is  truly  amazing  and 
very  definitely  influences  what  we  expect  in  the  future. 

LSI  technology  and  the  reduced  cost  of  electronic  hardware  would  tend  to 
support  a hardware  distributed  network  approach.  Even  if  the  conmuni cation 
hardware  cost  is  appreciable,  the  cost  is  fixed,  it  can  be  controlled  and 
maintained  better  than  a system  where  the  communication  functions  are 


bundled  back  into  the  software  system. 


From  a control  point  of  view,  a distributed  network  is  inherently  more 
reliable  than  a centralized  network  and  may  be  more  important;  it  keens 
more  options  open  to  implement  a larne  variety  of  individual  customer 
control  strategies. 


But,  is  it  realistic  to  consider  the  many  process  communication  require- 
ments as  practical  subsets  in  one  general  functions/requirements  document? 


Many  of  our  decisions  in  TC5,  especi 
optimizing  network  level  do  involve 
This  thinking  must  be  factored  into 
the  TC5  functional  requirements  and 


ally  at  the  comprehensive  control  and 
future  trends  in  software  methods, 
our  decision  making  process  to  firm-up 
to  make  them  more  meaningful. 
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APPENDIX  VII 


TUTORIALS  PRESENTED  ON  THE  SUBJECT 
INTERFACES  AND  DATA  TRANSMISSION 


The  following  tutorial  documents  are  presented  here: 

1.  Bockett-Pugh , C.,  Dief enderf er , C.,  and  Farmer,  C. 
Comparison  of  Honeywell  TDC  Data  Hiway  with  Propos 
Guideline  for  Implementation  of  Industrial  Process 
Computer  Inter^Subsystem  Communication 

2.  Podlesny,  C.,  Fiber  Optic  Communications , Galileo 
Electro-Optics  Corp. 

3.  Wipfli,  John,  Yara,  Ron,  INTEL  8773  SDLC  Protocol 
Controller , Intel  Corporation. 
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This  paper  describes  the  characteristics  of  the  Honeywell 
TDC  Data  Hi;ay  In  the  forma r of  the  proposed  guideline. 

The  guideline  is  based  on  both  the  Purdue  Workshop  Functional 
Requirements  (ISA  SP72)  and  the  IEC  WG6  Functional  Requirements. 

I The  paper  is  Intended  to  aid  in  the  comparison  of  the  TDC  Data 

Hiway  with  these  functional  requirements. 


1.0  INTRODUCTION 

The  TDC  Hiway  is  based  on  the  proposed  guidelines.  The  TDC  Data  Hlvay 
is  optimized  as  a secure  and  efficient  data  link  for  process  control 
application.  Hence,  the  protocal  is  oriented  toward  31  bit  words  including 
5 b.J  t BCH  check  codes.  A single  16  Bit  word  of  data  can  be  read  or 
written  with  respectively  62  or  93  total  bits  of  information  transferred. 


2.0  APPLICATION  ENVIRONMENT 

The  TDC  Hiway  is  intended  for  use  in  the  applications  as  outlined 
in  the  proposed  guideline. 


3.0  FUNCTIONAL  SPECIFICATION 

3.1  Topology 

The  TDC  Hiway  is  a dual  (redundant)  cable  system  of  the  multi- 
drop, multiple  branch  type. 

3.2  Mastership  in  Industrial  Dataway  System 

The  TDC  Hiway  supports  multiple  mastership.  "Preferred  Access" 
devices  (such  as  computers,  and  operator  consoles)  obtain 
mastership  from  the  Hiway  Traffic  Director. 

The  Hiway  Traffic  Director  does  not  function  as  a master  but 
as  a priority  scheduler  for  the  various  masters. 

3.3  Transmission  Speed 

The  TDC  Hiway  operates  at  a raw  bit  rate  of  250,000  bits  per 
second. 

3.4  Transmission  Distance 

The  Hiway  Traffic  Director  supports  three  radial  branches. 

Each  branch  may  be  1.5  km  (5,000  ft.)  long,  so  that  a total 
end  to  end  distance  of  3.0  km  may  be  configured.  Figure  1 
Illustrates  the  Hiway  System. 


I 
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Ft'HIRF  1:  HI  WAY  CONFIGURATION 


BKANCH 

C 


K~*l 

1.5  km  CABLE  LENGTH 


NOTE:  Each  branch  may  have  up  to  1.5  km  of  cable,  HTD 
mav  be  at  the  end,  or  anywhere  In  the  middle  of 
the  branch. 


3.5  Number  of  Stations  Per  Datawav 

The  TOC  Hlway  supports  63  stations. 

3.6  Number  of  Devices  Per  Station 

The  TOC  Hlway  supports  stations  having  varying  numbers  of 
devices  (Sec.  3.7).  lip  to  1024  locations  are  directly 
addressable  In  each  device.  Additional  locations  may  be 
addressed  indirectly. 

3.7  Types  of  Devices 

The  TOC  Hlway  supports  these  type  devices:  1)  Process 
Controllers;  2)  Process  Interface  Units;  3)  Operator 
Stations;  and  4)  Computer  Interfaces. 

The  characteristics  of  these  devices  are: 

1)  Process  Controllers:  This  device  provides  eight  loops  of 
process  control , with  sixteen  analog  Inputs  and  eight  analog 
output  s . 

2)  Process  Interface  Units:  These  devices  provide  analog 
Inputs  (high  level  and  low  level),  analog  outputs,  digital 
inputs  and  digital  outputs. 

3)  Operator  Station:  This  device  performs  the  functions  re- 
quired for  operator  control  of  the  process.  It  includes 
a CRT  display  and  functional  keyboard.  Specialized  dis- 
plays are  provided  for  overview  of  control  loops,  group  of 
control  loops,  and  detail  of  a single  loop  as  well  as  other 
cont igurat Ions . 
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4)  Computer  Interfaces:  These  devices  allow  computers  to 
access  information  from  the  other  devices  located  on  the 
Hiway.  The  computer  may  be  performing  direct  digital 
control  or  supervisory  control  type  functions. 

1.8  Mode  of  Transmission 

Bit  Serial 
Half  Duplex 

3.9  Priority  Control  of  Transmission 

1)  Bus  Master  devices  such  as  Computer  Interfaces  and  Operator 
Stations  obtain  use  of  the  Hiway  by  means  of  Preferred 
Access  lines  connected  to  the  Hiway  Traffic  Director. 

Access  is  reassigned  when  traffic  is  quiescent  for  80  jusec. 

2)  Asynchronus  Event  Detection  is  communicated  by  the  Process 
Interface  Unit  utilizing  polling  and  callup  commands  over 
the  Data  Hiway  from  the  Hiway  Traffic  Director.  These 
polling  commands  occur  when  communications  is  quiescent 
600  .us  or  is  scheduled  after  10  ms  if  traffic  does  not 
have  600  jus  gap. 

3.10  Response  Time 

Asynchronus  events  are  serviced  nominally  at  10  ms  intervals. 

3.11  Modulation  and  Synchronization 

Data  is  transmitted  using  the  base  band  modulation  technique 

shown  in  Figure  2. 

3.12  Type  of  Connection 

Coaxial  Cable  with  Tee  Connector. 

Three  twisted  pair  for  preferred  access*  with  screw  terminal  connections. 

3.13  Expandability 

The  TDC  Hiway  can  be  expanded  with  no  effect  on  operations. 

3.14  Environmental  Conditions* 


1) 

Temperature  : 

-20°C 

to  80°C 

2) 

Humidity  : 

Full 

Weather  Cable 

3) 

Earth  Potential  : 

250V 

4) 

Voltage  Breakdown  : 

250V 

* Applies  to  cable  system. 


[ 
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4.0  ARCHITECTURE 

4.1  System  Structure 

1)  Physical  l.ink:  The  physical  link  Is  75it  coaxial  cable  with 
associated  BNC  connectors.  The  coupler  to  the  Individual 
stations  is  through  a tee  connector. 

2)  Communication  link  and  logical  connection  are  combined  in 
the  various  interfaces  to  the  TDC  Data  Hiway. 

3)  Network  Control:  The  TDC  Hiway  network  control  furctions 
are  performed  by  the  Hiway  Traffic  Director. 

4)  Application:  The  TDC  Hiway  supports  various  application 
protocols  as  exemplified  by  the  TDC-2000  Basic  Controller, 
and  the  TDC-7100  Process  Interface  unit. 

4.2  Frame  Structure 

1)  Messages:  The  TDC  Hiway  uses  messages  made  up  of  31  bit 
words.  The  words  may  be  utilized  to  perform  single  word 
read,  or  write  messages;  block  read,  or  write  messages; 
and  control  (poll  or  callup)  messages. 

Figures  3,  4,  5 illustrate  these  messages. 

2)  Words:  The  format  of  the  31  bit  words  transmitted  over 
the  TDC  Hiway  is  shown  in  Figure  6.  Note  that  5 bits 

are  used  as  check  bits  (31,  26  BCH  CODE)  with  the  remainder 
available  for  information. 
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FIGURE  6:  WORD  FORMATS 
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b.o  protocol 

5.1  Physical  Link  Protocol 

1)  Transmission  rate  250K  bits/second 

2)  Data  Is  transmitted  utilizing  baseband  modulation,  as 
shown  in  Figure  2.  The  data  is  self-clocking  and  contains 
no  l).C.  component. 

3)  Bit  Synchronization  is  obtained  by  extraction  of  a clock 
signal  from  the  transmitted  bit  waveform. 

4)  Transformer  isolation  is  utilized  between  individual  stations 
and  the  transmission  line. 

5)  Separate  cable  driving  and  detection  circuits  are  provided 
for  use  in  conjunction  with  the  redundant  cables. 

6)  BNC  Tee  Connectors  are  used  to  connect  the  coaxial  cables 
to  every  hiway  device.  Thus  the  tee  may  be  disconnected 
from  the  station  without  disconnecting  the  transmission 
line . 

5.2  Communication  Link  Protocol 

1)  Data  is  transmitted  as  31  bit  words.  A six  bit  field 
(Destination  Hiway  Address)  allows  transmission  to  any 
one  of  the  63  stations. 

2)  The  31  bit  words  are  formatted  to  include  a Bose-Chaudhuri- 
Hocquenghem  (BCH)  - 31,26  - check  code.  The  characteristics 
of  this  code  are: 

a)  Detection  of  all  burst  errors  of  5 bits  or  less. 

b)  Detection  of  all  combinations  of  2 random  bit  errors 
or  less  are  detected. 

c)  Detection  of  all  single  inversions  of  message. 

d)  Detection  of  98. 5Z  of  pll  burst  errors  of  length  6 bits. 

e)  Detection  of  97%  of  all  burst  errors  of  length  greater 
than  6. 

3)  Error  recovery  is  performed  by  retransmission  under  control 
of  program  in  device  which  originated  the  message.  Missing 
response  and  incomplete  response  checks  are  included  in  the 
hardware. 
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4)  All  preferred  devices  (masters)  are  responsible  lor  error 
analysis  and  switching  to  backup  transmission  cable.  Slave 
stations  perform  error  checks  and  take  no  action  on  messages 
containing  an  error,  they  respond  on  the  cable  which  Is  cur- 
rently active. 

5.3  Logical  Connection  Protocol 

The  preferred  device  interfaces  perform  the  functions  of 
requesting  access  to  the  Kiway  automatically  upon  receipt  of 
an  Instruction  to  transmit  a message.  A watchdog  ciraer  is 
Included  In  the  Interfaces  to  detect  failure  to  receive  pre- 
ferred access  grant. 


6.0  SAFETY  AND  SECURITY 

6.1  Transmission  Error  Processing 

1)  BCH  Check  Code  - generated  and  checked  on  all  transactions. 

2)  Bit  Correlator  - receivers  check  all  bits  for  presence  of 
both  pulses  in  every  bit. 

3)  Start  Bit  - check  that  first  bit  of  every  word  is  a one. 

4)  Operation  Code  Checking  - devices  check  that  each  word 
has  proper  OP  CODE  e.g.  a data  word  response  to  a read 
command . 

5)  Automatic  Retry  - software  functions  to  retry  transactions 
which  result  in  an  error  response  up  to  three  times. 

6)  Timeout  Functions  - Time  checks  are  performed  on  receipt 
of  Data  Word  or  Echo  within  designated  time  period. 

7)  Dropout  Detector  - Missing  bits  are  detected  in  the  middle 
of  words  to  eliminate  forming  31  bit  word  out  of  two 
partial  words. 

8)  Jabber  Halt  - A fail  safe  circuit  designed  into  each  station 
to  prevent  continuous  transmission. 

9)  ECHO  - a retransmission  by  receiver  of  DATA  WORD  (or  last 
word  of  a block  of  data  words)  is  performed  as  part  ol 
every  write  message  to  positively  acknowledge  the  receipt. 

10)  Redundancy  - All  functions  of  HTD  are  performed  in  redundant 
logic.  Coaxial  cables  are  redundant.  Cable  driver  and 
detector  circuits  are  redundant  in  every  station. 
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6.2  System  Failure  Detection,  Protection,  and  Recovery. 

1)  Transformer  Isolation  - All  stations  are  Isolated  from 
the  transmission  line  so  that  a component  failure  does  not 
affect  system  operation. 

2)  Switch  to  Redundant  Hiway  - The  master  stations  can  decide, 
based  on  analysis  of  system  performance,  to  switch  to 

the  redundant  hiway.  Manual  control  Is  also  provided  at 
the  HTD. 

3)  HTD  Alarm  - The  HTD  monitors  Its  own  polling  activity 
which  is  indicative  of  Hiway  loading  to  determine  if  the 
Hiway  is  overloaded. 

4)  Manual  override  of  HTD  grant  signals  is  possible  to  disconnect 
a failed  master  device. 

6.3  Other  Features 

1)  Preferred  Access  Expander:  This  device  allows  expansion 
of  a Data  Hiway  System  beyond  the  four  supported  by  the 
basic  HTD. 

2)  Hiway  Repeater:  This  device  allows  expansion  of  a Data 
Hiway  System  beyond  the  1.5  meter  limit. 

3)  Power  Distribution:  All  TDC  controllers  and  PIU's  operate  off  a 24VDC 
power  bus.  This  bus  may  be  driven  by  redundant  power  supplies, 
and/or  a battery  backup  system. 

The  HTD  uses  redundant  regulators  to  power  the  separate 
logic  functions. 


7.0  MAINTENANCE 

7.1  On  Line  Maintenance 

The  operator  station  performs  an  on  line  maintenance  function 
for  the  Data  Hiway.  A program  runs  periodically  to  determine  the 
status  of  all  stations  on  the  Hiway. 

A display  is  generated,  which  can  be  initiated  from  the  keyboard, 
to  indicate  which  stations  are  not  operable  and  the  reason. 

The  station  retries  all  communication  errors  up  to  three  times 
and  logs  those  failures  as  a basis  for  the  switch  decision. 

7.2  Off  Line  Maintenance 

A Hiway  Exerciser  is  available  to  manually  perform  opeiations 
over  the  Data  Hiway  for  the  purpose  of  validation  of  the  Hiway 
operation,  or  maintenance  of  individual  stations  disconnected 
from  the  Hiway. 


COMPARISON  SJWRY 
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This  comparison  describes  the  characteristics  of  the  Honeywell 
TDC  Data  Hiway  in  the  format  of  the  Japanese  Proposed  Guideline. 


The  TDC  Hiway  is  optimized  as  a secure  and  efficient  data 

LINK  FOR  PROCESS  CONTROL  APPLICATIONS.  The  PROTOCOL  IS  ORIENTED 
AROUND  31  BIT  WORDS  INCLUDING  5 BIT  BCH  CHECK  CODES.  A SINGLE 
16  BIT  WORD  OF  DATA  CAN  BE  READ  OR  WRITTEN  WITH  63  OR  93  TOTAL 
BITS  OF  INFORMATION  TRANSFERRED. 


mCMBSM  PACK 
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Priority  Scheduler 

Preferred  Access:  Request/Grant  Polling  & Callup 


Cable  Selector 
Manual 


Remote  Control 


Repeater 

Three  1.5  kilometer  (5000')  branches 


COMPARISON  SUMMARY 
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pKiOKtry  Control  or.  Tkansmssjon 

1)  Link  Master  devices  such  as  Computer  Interfaces 
and  Operator  Stations  obtain  use  of  the  H i way  by 
means  of  Preferred  Access  lines  connected  to  the 
Niway  Tratfic  Director.  Access  is  reassigned  whin 

TRAFFIC  IS  QUIESCENT  FOR  80  /USEC. 

2)  Asynchronous  Event  Detection  is  communicated  by 
the  Process  Interface  Unit  utilizing  polling  and 

CALLUP  COMMANDS  OVER  THE  DATA  II I WAY  FROM  THE  III  WAY 

Traffic  Director.  These  polling  commands  occur 

WHEN  COMMUNICATIONS  IS  QUIESCENT  600  JJS  OR  IS  SC  HE  DIM  LD 
AFTER  10  MS  IF  TRAFFIC  DOES  NOT  HAVE  600  JJS  GAP. 


WG6  (JAPAN  2)  DATA  HI WAY 


6)  Redundant  Paths  6)  Cables  & Driver  Detector 

7)  Bypassing  & Dis-  Circuitry 

connect  I 7)  &NC  TEE  Connectors 
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Sendcr 


Receiver 


Sender 


Legend 

CK  - Read  Co  r.  iand 
BD  - Block  Data  Word 
WN  - Data  Word 


Receiver  Legend 

CW  - Write  Command 
BD  - Block  Data  Word 
WD  - Data  Word 


BLOCK  It  LAD  MESSAGES 


. , RDN  WD 

-» 1 1 1 


WTN+2  WTN+3 


BLOCK  WRITE  MESSAGES 


WTN+ 1 WTN+2 


WTN+3 


♦ ini  * 
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Transmission  Error  Processing 

1)  3CH  Check  Code  - generated  and  checked  on  all  transactions. 

2)  3it  Correlator  - receivers  check  all  bits  for  presence 

OF  DOTH  PULSES  IN  EVERY  BIT. 

3)  Start  Bit  - check  that  first  bit  of  every  word  is  a one. 

1)  Operation  Code  Checking  - devices  check  that  each  word 
has  proper  Op  Code,  e.g.,  a data  word  response  to  a 

READ  COMMAND. 

3)  Automatic  Retry  - software  functions  to  retry  transactions 

which  result  in  an  error  response  up  to  three  times. 

6)  Timeout  Functions  - Time  checks  are  performed  on  receipt 

of  Data  Word  or  Echo  within  designate:  time  period. 

7)  Dropout  Detector  - Missing  bits  are  detected  in  the 
middle  of  words  to  eliminate  forming  31  bit  word  out  of 
two  partial  WORrS. 

8)  Jabber  Halt  - A fail  safe  circuit  designed  into  each 
station  to  prevent  continuous  transmission. 

3)  ECHO  - a retransmission  by  recciver  of  DATA  WORD  (or 

LAST  WORD  or  A BLOCK  OF  DATA  WORDS)  IS  PERFORMED  AS  PART 
OF  EVERY  WRITE  MESSAGE  TO  POSITIVELY  ACKNOWLEDGE  THE 
RECEIPT. 

10)  Redundancy  - all  functions  oi  !!TD  arl  performed  in 

REDUNDANT  LOGIC.  CoAXIAl  CABLES  ARL  REDUNDANT.  C.ARLE 
DRIVER  AND  DETECTOR  CIRCIII1S  ARE  REDUNDANT  IN  I VERY 
STATION. 


i 
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Data  Hjway  Error  Detection 


Bit  Error 

Prob.  of 

Z fcLV-U 'w'-'Wlm 

"Worst  Case" 

Word 

Probability 

3 OR  MORE 

Probability 

Proba 

(PE) 

Bit  Errors 

(31,26)  BCH 
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-l 

10 

-l 

10 

Code  Fails  To 
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.03 

10 

-10 

10 

-27 

10 

.03 

10 

__  -5 

P > 2.  x 

31 

31 

( , ) PJ 

J E 

(1  - P ) 3T-J 

E 

J = 

3 

-536- 


' 
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K-H  9/23/77 

R.  Sander 

C.  Dtefenderfer 

S.  Korowitz 

C . Fanner 

RSC 

(1)  Connections 

(2)  as  given  in  IEEE  488 

JAPAN 

IEC 

COMPARISON 

1.0 

1.0 

Narrative 

2.0 

2.0 

Narrative 

3. 1 

4.0 

Narrative  4 Schematic 

3.2 

4.2,  7.6.2 

Narrative  4-  Specific  Answer  to  4.2 

3.3 

3.4 

Numbers  4 Qualification 

3.4 

3.4 

Numbers  4 Qualification 

3.5 

4.3 

Numbers  4 Qualification 

3.6 

4.3,  3.1.1 

Numbers  4 Qualification 

3.7 

3.1.1 

List  of  Device  Types  4 Descriptions 

3.8 

7.4 

Attribute  List 

3.9 

7.5.9 

Narrative  with  Numbers 

3.10 

7.5.9,  11.2 

Number  4 Qualification 

3.11 

7.4,  7.4.3 

Diagram  4 Description  - Redefine  as 
Transmission  Media  4 (1) 

3.12 

List  4 Descriptions 

3.13 

4.3,  4.4, 
7.5.6 

Narrative  4 Specific  Answer  to  4.4 

3.14 

2.4,  2.5, 
3.4.1,  3.4.2, 
8.2,  8.3 

Numbers  4 Qualification  4 Statements 

4.1 

7.1 

Block  Diagram  4 Narrative 

4.2 

7.4,  7.5 

Detailed  Narrative  4 Diagram 
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JAPAN 

IEC 

COMPARISON 

5.1 

7.3,  7.4 

List  of  Attributes  with  Description- 
including  all  elements  of  Japan 
plus  physical  configuration  7.3  to 
7.3.4  with  explicit  answers  to 

7.4.1  to  7.4.6  including  state 
transition  diagram  (2) 

5.2 

7.3,  7.5 

Same  as  5.1  except  7.3.1  to  7.3.4  & 
7.5.1  to  7.5.9 

5.3 

7.3,  7.6, 
7.7,  7.8 

List  of  Attributes  with  Description  ■ 
Specific  Answers  to  7.3.1  to  7.3.4  & 
7.6.1  & 7.6.4 

6.1 

9.1,  9.2 

List  of  Attributes  with  Descriptions 
Including  all  elements  of  Japan  2 

6.2 

10.0 

List  of  Attributes  with  Descriptions 
including  specific  answers  to  10.1  - 
10.4 

6.3 

8.0,  10.0 

See  below 

7.1 

6.1,  6.2. 
3.1.4 

Narrative  & Philosophy 

7.2 

6.1,  6.2, 
3.1.4 

Narrative  & Philosophy 

3.1.2 

List  of  Device  Types  & Description 

3.1.3 

List  of  Device  Types  & Description 

3.1.5 

Statement  of  any  restrictions  on 
simultaneous  operation  of  devices 

5.0 

State  avoidabillty  of  translators 
Common  carrier  Interfaces  available 

8.0 

Narrative  answers  to  8.1  to  8.3 

11.1 

Specific  example  calculations  for 
short  and  long  transfers  from  Master 
to  Slave  and  Slave  to  Master 
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IEC/SC65A/NC6  SECTIONS  FOR  WHICH  NO  RESPONSE  IS  REQUIRED 

1.1,  1.2,  1.3 

2.1,  2.2.  2.3 

3.2,  3.3,  3.5 

7.1,  7.2,  7.7,  7.8 

4.1.  4.3 


SPECIFIC  OBJECTIONS  TO  IEC/SC 

7.3.2  cannot  apply  to  all  aspects  of  physical  protocols 
State  explicitly  the  nature  of  all  time/distance 
dependencies . 


7.6.5  The  logical  connection  protocol  must  address 
the  question  of  data  integrity  on  transfers  between 
the  application  protocol  and  the  communication  link 
protocol.  An  example  is  check  before  operate. 


11.2  Give  examples  calculations  of  response  times 
under  the  assumption  of  various  traffic  patterns  and 
device  response  characteristics. 


PSEUDO  RANDOM  SEQUENCE 
• IT  GENERATOR 


n»t«  OPTit 
(OMMIMrCArMVS 


ROTATION  10  i HE  lECHNOtOCy 
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ADVANTAGE5  OF  FIBER  OPTIC 
COMMUNICATION  SYSTEMS 

O IMMUNITY  TO  STRONG  ELECTRIC  amo/ob.  MAGNETIC  NOISE  FIELDS 
o DIELECTRIC  ISOLATION  BETWEEN  TRANSMITTER  AND  RECEIYE2 
o WIDE  FREQUENCY-  INDEPENDENT  BANDWIDTHS 

STEP  INDEX  GRADED  INDEX 

20 40  MHa/lc^  O...I200  NHi/u 

© 'secure*  tpansmisson  MEDIUM 

o NEGLIGIBLE  CROSS-TALK  BETWEEN  CHANNELS  (GO.  30  As) 
o.  ADVANTAGES  OVER  COMPARABLE  COAXIAL  SYSTEMS 
SMALLER 
LIGHTER 
LOWER  LOSS 

TEMPERATURE  STABLE  (-55...*l25*c) 

NO  EQUALIZATION 
(lower  cost) 

o $IOO  MILLION  TECHNOLOGY  BY  I9BO 
COMMUNICATIONS 
COMPUTERS 

BUSINESS  DATA  SYSTEM 
INDUSTRIAL  PROCESS 
INSTRUMENTATION  AND  CONTROL 


BIAS 
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Cable  Characteristics 


OPTICAL 

• SPECTRAL  RESPONSE  (ATTENUATION} 

• DISPERSION  BANDWIDTH 

• NUMERICAL  aperature 

CALCULATED 
STEAD/  - STATE 

• equalization  length 

• ACTIVE  AREA 

• FIBER  COUNT 

• OPTICAL  ISOLATION 

NEAR  - END 
FAR  - END 

• CLAD  MATERIAL 

MECHANICAL 

• tensile  strength 

• FLEXIBILITY  (TWIST  AND  BEND) 

• CRUSH  RESISTANCE 

• IMPACT  RESISTANCE 

• ABRASION  RESISTANCE 

• CABLE  DIAMETER 

• MINIMUM  BEND  RADIUS 

• FIBER  BUFFERING 

• EASE  OF  TERMINATION 

ENVIRONMENTAL 

• TEMPERATURE 

• MOISTURE  RESISTANCE 

• CHEMICAL  RESISTANCE 


I 


f 


Optical  Waveguide 
Numerical  Aperture 


/ JCLADIWG 


WHEN  0*9c  TOTAL  internal  reflection  occurs 

0C  = COS"'  * CLAD 
n CORE 


N.A.  Y\2  - ft1 
Vc«f  Cmo 


50.J5>*/7>  i 


ATTENUATION  dB/Kt* 
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/ 2 . 5 tO 


NfODUL  A 


AT  T £ 


SINGLE-FIBER  TECHNOLOGY 

(ONE  FIBER-ONE  OPTICAL  CHANNEL ) 

o GLAMOR  TECHNOLOGY 
O DIFFICULT  TO  IMPLEMENT 
o STRONGEST  FIBERS -BUT  EXPENSIVE 
o ¥EASY*  TO  END  -TERMINArE 
o LOW  LOSS -BUT  LOW  N.A. 
o POOR  COUPLING  EFFICIENCY  (NIGH  I.L.*) 
o FEW  CONNECTOR  SUPPLIERS  (EXPENSIVE  LOSS 
o IN -LINE  SPLICING  TECHNIQUE  POPULAR 

EASY 

LOW-COST 
LOW -LOSS 
REPEATABLE 

• MEDIUM  TO  VERY -HIGH  BANDWIOTHS 

STEP  INDEX  GRADED  INDEX 

20"— 40  MH»/k*m.  250—1400  MH*7w 

o TYPICAL  SIUGLE  FIBER  CHANNEL  CHARACTERISTICS 
POINT-TO-POINT  TRANSMISSION 
LONG  HAUL  (0.5  frm.) 

PERMANENT  LONG-TERM  INSTALLATIONS 
DIGITAL 

PIG-TAIL  ILDs 
(PiG-TAlL)  APDs 

o STANDARD' CABLE  FIBER  COUNTS  ! 1 ,G  ,(7) 
o EACH  FIBER  OPTICALLY  ISOLATED  (60 - — BOd B/ ton.) 
c APPROXIMATELY  1.3  mSec/mr  SIGNAL  DELAY 
o LIGHT,  MEDIUM,  AND  HEAVY-DUTY  CABLES  AVAILABLE 
o SEVERAL  SUPPLIERS: 

CORNIWG/SIECOR  — GALILEO/ eEVERE  - VA IT  EC 
ITT/EOPD  TIMES  FIBER 
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Bundle  Technology 

(multi-fiber  optical  channel) 

° Mature  Technology 
° Easiest  to  Implement 
° Cheapest  to  Implement 
° Redundant  Path  Reliability 
o Poor  Fiber-to-Fiber  Isolation 
° Easy  to  Eno  Terminate 
0 Multitude  of  Connector  Suppliers 
o Compatable  with  Low  Cost  L E D s ' 
o Aoeouate  Bandwidth  for  TTL.  Logic  Speeos 
° Characteristically  High  N.A.  (040...0  66) 
o Three  Basic  Classes* 

DISTANCE  c.ncp  rot  in  T ATTEMJATION 

lUETCRS)  £IB£R  C0wr  (dBlk-J  

/ 30  200  4C0-  500  0 66 

SO  . K)0  7,191s?)  50—100  0.40  .0  50 

100-1000  7 5-25  0 2 0.4 


o Light,  Medium,  a Heavy  Duty  Cables  Available 
° Hyirio  Cables  Available  (coax,  stp,  fikr) 

° Various  Suppliers 
° Typical  Pricing  (pvc  jacket} 


Gauti 


1000/200 

2000/200 

sooo/t 


till 

0. 50...0./B 
0.90  .053 
I.20...0  53 


° Worst-case  BW  F'OM-o t 20MHz-R^ 
o Approximately  I.5~sec/ft  Signal  Delay 


The  EMI-Free  Coaxial  Cable  — - 


ASSUMPTIONS 

1.  EACH  FIBER  HAS  SAME  N.A. 

2.  '• 

11  n n 

ATTENUATION 

3.  •• 

11  11  11 

LENGTH 

4.  •' 

u 11  n 

C/C- RATIO 

5.  " 

11  11  u 

CORE  SIZE 

BREAKAGE 

EXCESS  LOSS 

^5' 

g 

cn 

0 

O 

[dB] 

Nr0RI6INAL  FIBER  COUNT 
✓n=  BROKEN  FIBER  COUNT 

ATTENUATION  INCLUDING  BREAKAGE  LOSS 

^*CA»LS'  d B 

L<*=c**  [dB' 

EXAMPLE 

GALITE®  3000/19  ® 880  mjyy\ 

1 » 100  METERS  0<  *70  dB/k/m. 
FIVE  BROKEN  FIBERS 
L * 7.0  ♦1.33 


BASICS  OF  FIBER  OPTIC  POWER  TRANSMISSI 


»**•  v*H 


RTI  and  OL M 

RADIATION  TRANSFER  INDEX  LOSS 

LaTX»-|00LO9,o(RTI)  [AB] 

TOTAL  TRANSMISSION  LOSS  (TOLM) 

L «L  + 1 +1. ♦ L >L  + L fcLBl 

T Cl  <K  w*  P *"00  TV  L j 

wmebk  L = L *L  ♦ L ♦!  L ” 6 

CX  AM  PP  P X UA  V. 

ALLOWABLE  OPTICAL  LOSS  (OLM~) 

Lm=P»a-(NEPT+SWK+Lt)  [<iB] 

TYPICAL  OLMs 


[dB] 


— DIGITAL  — 

LED  (l  niw) 

APD 

10  M b ps 

BER  $ \Q'n 
NEPT  = - 55<LBt« 
SNRe»22<tB 

LM  = 30dB  (RTI=0.5) 


-VIDEO  - 

LED  (lmw) 

PI  Kl 

5.0  MH£ 

SNR  = 45  dB 
NEPT=-4545-m 
L„  = I54B 


Radiation  Transfer  Index 


NQTH  (ME  TERS 
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ALLOWABLE  OPTICAL  LOSS 


TOLM 


OLM 


OPTICAL 

1055 

(LMT) 


Po(5WB=  l) 


L^P^-NEPTfiB] 


Pa  a 


OPTICAL 

LOSS 

(iM) 


P«(SNR=K.) 


lmsp9a-not-snbd  [«lb] 


LOSS  FACTORS 


‘-,,'P3»-[tL*NEPr+SNe][-clBi 


Attenuation  and  Dispersion  Limited  Operation 
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COMMON  MODULATION  TECHNIQUES 

o CARRIER  (NON-PHASE  COHERENT) 

ANAL06  INTENSITY  MODULATION 
ON-OFF  KEYING  (OOK) 

PCM 

PFM  (PIM) 

POM 

PWM 

o SUBCARRIER  (PHASE  COHERENT) 

AIM/ AMPLITUDE  MODULATION  (AIM/AM) 

AIM/  FREQUENCY  MODULATION  (AIM/FM) 

« BITS  AND  BAUDS 

BAUD -I  "SIGNALING  RATE 

I — -CODING  INDEPENDENT 
I — -INFORMATION  RATE 
B ' — -CODING  DEPENDENT 

O 

« UNIPOLAR  INFORMATION  CARRIER  (PHOTONS) 

OATA  COOING  REQUIREMENT 
DC  BASELINE  WANDER 

COMMON  MULTIPLEXING  TECHNIQUES 


O TIME  DIVISION  MULTIPLEXING  (TDM) 

® FREQUENCY  DIVISION  MULTIPLEXING  (FDM) 
o WAVELENGTH  DIVISION  MULTIPLEXING  (WDM) 
« SPACE  DIVISION  MULTIPLEXING 
° COMBINATIONS  OF  ABOVE 


AVERAGE  POWER  (d8^) 


A 


TRANSMISSIVE  STAR 


Fiber  Optic  Data  Bus  CoNfK;uf?ATioNs 


f 
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T~ 


Medium  Cost/S  peed  Data  Link 

* MTA  RATE  £ 10 

* ROOM  TEMPERATURE  (ZS*  C t-  10m C\ 

* C0PIW6  TRANSPARENT 

M ONE  MICROWATT  7WTCSWJLD  (jTTV  OUTPUT^ 
m MICRO  PROCESSOR  -TO  - MINI  COM  PVT  fH 
« ELECTRONICS  COST  h.  * Jo  z±  (0«C  EAOt) 

* CABLE  COST  it  f I •£  / FOOT 

41  CdUNCCTDR.  COST  i / PCR  PAIR 

W DISTANCE  Sr  100  FEET  £00  <18  Km  • U.A.  -O.tfr 
« BALANCED  PM  OlOOC  lCAkAAE  CURRENT 


CURRENT  -TO-  V0L.TA6E  CONVERTER  BANDA/IDTH  (_IO  < fl) 


f-JJB 


i 

TrfTc  * 


0-J.f 

tr,  0°-**°^) 


IS. A PMZ 
C.  ^lO"  F 


— PREAMP  TOTAL  WISE  RISE  TIME 

kf  « V*ri  Tt,.\  »*5«  SEC  Pint  »w) 

,v  0.35 

(«‘W)  "*«  v.  *1^ 

— >SlO«  COMPARATOR  SUPPRESSES  COWMAN -MOOT  DRIFT 

— t<v  fc-4  >SJ  ElMV  with  \*KU  savRCt 

— tMp.  VKMt  AT  COMPARATOR  (nS<SC  VOLTAfcc} 


lA 


Cost- Performance  Trade-off  Summary 
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ANT1C1PATED  FIBER  OPTIC 
CABLE  IMPROVEMENTS 

O REDUCED  LOSS  (CABLED) 
o LARGER  NJ.A.s 
© WIDER  BAK1DWIDTHS 

© INTRINSIC  MATERIAL  DISPERSION  COMPEKJSAT/OM 
© IMPROVED  STRENGTH 
© IMPROVED  DIMENSIONAL  TOLERANCES 
© LONGER  LENGTHS 

o LIGHT,  MEDIUM,  AND  HEAVY- DUTY  CONFIGURATIONS 
© HYBRID  CONFIGURATIONS  (FIBER, COAX, STP) 


! 

i 


ASSUMES  TYPICAL  (6  -FIBER)  CABLE 


(inan/i)  3omd 


; 

i 


SDLC  PROTOCOL  CONTROLLER 


JOHN  WIPFLI 


INTEL  CORPORATION 
SANTA  CLARA,  CALIFORNIA 
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OUTLINE 

OVERVIEW 

I.  SDLC  PROTOCOL 

II.  8273  LEVEL  OF  SDLC  SUPPORT 

III.  MICROPROCESSOR  TO  DEVICE  INTERFACE 

IV.  IMPORTANT  FEATURES  OF  8273 

,/ 

V.  OPERATING  CHARACTERISTICS  j >' 

VI.  AN  INTELLIGENT  PROCESS  CONTROL  NODE 

VII.  LSI  IMPLEMENTATION 

SUMMARY 


JfiKCXQINQ  FjtQS  bi  Any 


LAYERS  OF  A COMMUNICATIONS  SYSTEM 


APPLICATION 


LINK 

COUPLER 


DATA  STREAM  WITH  DESTINATION  (S) 


DATA  STREAM  WITH  NETWORK  ROUTING 
AND  CONFIGURATIONS 


DATA  STREAM  WITH  SUBSYSTEM 
ADDRESSING 


DATA  STREAM  WITH  HEADERS, 
TRAILERS,  AND  ERROR  CHECKS 


PHYSICAL  INTERFACE 
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1.  SYNCHRONOUS  DATA  LINK  CONTROL  (SDLC) 

COMMUNICATION  DISCIPLINE  USED  BY  IBM  TO 
IMPLEMENT  SYSTEM  NETWORK  ARCHITECTURE  (SNA) 

IBM,  SDLC  PROTOCOL  CHARACTERISTICS 

• BIT  ORIENTED  PROTOCOL 

• ZERO  BIT  INSERTION/DELETION  FOR  DATA  TRANSPARENCY 

• CYCLIC  REDUNDANCY  CHECKING  (CRC)  FOR  ERROR  DETECTION 

• VARIABLE  LENGTH  DATA  FIELDS 

• MULTIPLE  MESSAGES  MAY  BE  SENT  BEFORE  ACKNOWLEDGEMENT 
IS  REQUIRED 

• STATION  ADDRESSABILITY  AND  CONTROL  FUNCTIONS  ARE 
SPECIFIED 

• TIMEOUTS  FOR  LINK  IMPASSE 

• MULTIPLE  CONFIGURATIONS  SUPPORTED: 

DUPLEX 
HALF  DUPLEX 
MULTIPOINT 
LOOP 

\ 


MULTIDROP 
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SDLC  FRAME  STRUCTURE 


(D 

XflagXT 


V /— 

DATA 

Jh~ 


FCS 


FLAG 


-TRANSMIT  DIRECTION 


FUG:  01111110  ATTAIN  BIT  SYNCHRONISM  CD 

TERMINATE  MESSAGE  @ 

A:  ADDRESS  FIELD  (STATION  ROUTING)  8BITS 

C:  CONTROL  FIELD  (CONTROL/SEQUENCING)  8BITS 

DATA:  VARIABLE  NUMBER  OF  BITS 

FCS:  16  BIT  CRC  REMAINDER 

CRC-CCITT  POLYNOMIAL  (X16  + X12  + X5  +1) 
VALIDATES  A,  C,  DATA 
FRAME  CHECK  SEQUENCE 


\ 
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1 1 . 8273  LEVEL  OF  SDLC  SUPPORT 


THE  8273  IS  A HARDWARE  IMPLEMENTATION 
OF  THE  SDLC  COMMUNICATION  LINK  LAYER. 


LOGICAL  CONNECTION  AND  NETWORK  CONTROL 
LAYERS  MUST  BE  IMPLEMENTED  WITH  nP  SOFTWARE. 

DUPLEX,  HALF  DUPLEX,  AND  LOOP  OPERATION 
IS  SUPPORTED,  ALLOWING  COMPLETE 
CONFIGURATION  FREEDOM. 


HI.  MICROPROCESSOR  (mP)  TO  DEVICE  INTERFACE 


CHARACTERISTICS 
HIGH  LEVEL  COMMAND  STRUCTURE 
FRAME  LEVEL  OPERATIONS 

(yKtZu)  ) 

DMA  - BASED  DATA  TRANSFER  -—MAXIMUM  SPEED  (56KBAUD) 
INTERRUPT  - BASED  DATA  TRANSFER  —MINIMUM  SYSTEMS 


MINIMIZATION  OF  uP  INTERRUPTS 


(9600  BAUD) 


PROGRAMMABLE  MODES  OF  OPERATION 


USRT  - UNIVERSAL  SYNCHRONOUS  RECEIVER/TRANSMITTER. 

DMA  - DIRECT  MEMORY  ACCESS 
MEM  - SYSTEM  MEMORY 

PROBLEM:  j 

SDLC  USRT  REQUIRES  CHARACTER  TIME 
RESPONSE  BY  »P  IN  MANAGING 
SDLC  FRAMES. 

l! 


8275 

SOLUTION: 

INTEGRATING  A SPECIAL  PURPOSE  »P 
WITH  THE  USRT,  REAL-TIME  EVENTS 
ARE  BUFFERED  FROM  SYSTEM  uP. 

8273  CAN  INDEPENDENTLY  MANAGE 
SDLC  MESSAGE  FORMAT 

CPU  INVOLVEMENT  MINIMIZED 


-5 


LAYERS  OF  A COMMUNICATIONS  SYSTEM 


TION 


LINK- 
COUPLER 


DATA  STREAM  WITH  DESTINATION  (S) 


DATA  STREAM  WITH  NETWORK  ROUTING 
AND  CONFIGURATIONS 


DATA  STREAM  WITH  SUBSYSTEM 
ADDRESSING 


8273 

DATA  STREAM  WITH  HEADERS, 
TRAILERS,  A^ID  ERROR  CHECKS 


PHYSICAL  INTERFACE 


MINIMIZATION  OF  v?  INTERRUPTS 
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IV.  IMPORTANT  FEATURES  OF  8273 

• DIGITAL  PHASE  LOCKED  LOOP  (DPLL) 

CLOCK  RECOVERY  TO  9600  BAUD 
SINGLE  LIGHT  PIPE/WIRE  PAIR 

• LOOP  CONFIGURATION  SUPPORTED 

ALA  - IBM  3650  RETAIL  STORE  SYSTEM 

• NUMEROUS  PROGRAMMABLE  MODES  OF  OPERATION 

NRZI  ENCODE/DECODE 
DIAGNOSTIC  DATA  LOOP  BACK 
USER  DEFINED  MODEM  CONTROL  PORT  PINS 
EFFICIENT  DMA  IMPLEMENTATION 
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V.  OPERATING  CHARACTERISTICS 

Ta  = 0°C  TO  70°C 

Vcc  5.0  V ± 10% 

ALL  INPUTS  AND  OUTPUTS  TTL  COMPATIBLE. 

INPUT  LEVELS 
VIL  MAX  = 0.8V 

VIH  MIN  = 2.0V 

OUTPUT  LEVELS 

V0L  MAX  = 0.4  V S 2.0  mA 

V0H  MIN  = 2.4V  a -200pA 

MOS  TECHNOLOGY  OFFERS  TTL  TERMINAL  CHARACTERISTICS 
AT  GREATLY  IMPROVED  FUNCTIONAL  DENSITY. 

8273  REPLACES  ~ 200  TTL  COMPONENTS  WITH  22,000  DEVICES 
ON  A SINGLE  CHIP 


VI.  AN  INTELLIGENT  PROCESS  CONTROL  NODE 


• SOLID  STATE  RELAYS 

• POWER  DARLINGTONS 


1 

"1 

1 

SUMMARY  1 

MINIMUM  COST  INTELLIGENT  NODE  1 

• 

MINIMUM  MICROPROCESSOR  OVERHEAD  1 

I • 

PROGRAMMABLE  NODES/SPECIAL  FEATURES  1 

; • 

MULTIPLE  CONFIGURATIONS  1 

1 LSI  TECHNOLOGY  HAKES  THE  ENTIRE  INTELLIGENT  NODE  POSSIBLE  1 

1;  USING  A MINIMUM  NUMBER  OF  PACKAGES:  1 

• 

8273  SDLC  PROTOCOL  CONTROLLER 

• 

8080/8085  INDUSTRY  STANDARD  J^P 

0 

8253  INTERVAL  TIMER 

• 

8259  INTERRUPT  CONTROLLER 

| 0 

\ 

RAMS  & ROMS 

John  Wipfli 
October  3,  1977 


SERIAL  OATACOMM  IN  A MICROCOMPUTER  SYSTEM  ENVIRONMENT 


THE  PROBLEM: 

MOVE  A BUFFER  OF  DATA  FROM  ONE  MPU  SYSTEM  TO  ANOTHER  USING  A SERIAL 
TRANSMISSION  DEVICE. 


ASSUMPTIONS: 


o SIMPLE  DATA  STRUCTURE 

i 


• 2MHZ  8080  SYSTEM 

• INTERRUPT  CONTROLLER  COSTS  NO  EXECUTION  TIME  LOSS 

• TRANSMITTER  IS  ONLY  OPERATING  DEVICE 

• NO  CHECKS  ON  TRANSMITTER  STATUS 

• HALF  DUPLEX  OPERATION 


LET'S  FIND  THE  MPU'S  LIMIT  ASSUMING  A HARDWIRED  COMMUNICATIONS  CHANNEL 


i 


COUNT 


POINT  • 


DATA 


I 


INTERRUPT  DEVICE  HANDLER  FOR  TRANSMITTER 


8080  "T"  STATES 


PUSH  D 
PUSH  H 
PUSH  PSW 
LHLD  COUNT 
XCHG 

LHLB  POINT 


NOV  M,A. 

IN  SDLC-DATA 
I NX  H 
DCR  E 
JNZ  NEXT 


CHANGE  CONTEXT 


TRANSFER  BYTE 


<SET  COMPLETION  FLAG> 


SHLD  POINTER 
XCHG 

SHLD  COUNT 
POP  PSW 
POP  H 


RESTORE  CONTEXT 

(66) 


RETURN 


8080  "T"  STATES  REQUIRED:  186 

93  JE.SI  C AT  2 MHZ 
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DINT: 


NEXT: 


IMPROVED  INTERRUPT  HANDLER 


PUSH  H 
PUSH  PSW 
LHLD  POINT 


MOV  A,M 
OUT  SDLC 
I NX  H 
SHLD  POINT 
LHLD  COUNT 
DCR  L 
JNZ  NEXT 


<SET  FLAG> 


SHLD  COUNT 
POP  PSW 
POP  H 


8080  "T"  STATES  REQUIRED:  157 

73  JISEC  AT  2MHZ 


8080  "T"  STATES 


CHANGE  CONTEXT 


TRANSFER  DATA 
(69) 


RESTORE  CONTEXT 


RETURN 


MINIMUM  CYCLE  » Si  S0  S\  S2  S3  S4 


» 6 8080  "T"  STATES  (3  J|SEC) 

MAXIMUM  CYCLE  = 6 "T"  + INSTRUCTION  LATENCY 

= 6 "T"  + 5 "T" 

* 11  "T"  (5.5  L| SEC) 


DEDICATED  DEVICE  HANOLER 

"T"  STATES 

DLOOP: 


IN 

SDLC-STAT 

10 

AN  I 

RXBF 

7 

(27) 

JZ 

DLOOP 

10 

MOV 

A,M 

10 

OUT 

SDLC 

7 

I NX 

H 

5 

(37) 

DCR 

C 

5 

1 

JNZ 

DLOOP 

10 

| 

RET 


8030  "T"  STATES  REQUIRED:  64 

32  IjSEC  AT  2MHZ 
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EVENT  TIME  TABLE 

HALF  DUPLEX 

' 

BAUD  RATE 

BIT  TIME 

BYTE  TIME 

2.0M 

500MS 

4 JJSEC 

1.5M 

666MS 

5.33  USEC 

l.OM 

U(SEC 

8 USEC 

250K 

4 MSEC 

32  JJSEC 

100K 

10  JLJSEC 

80  JJSEC 

64  K 

15.6  j|SEC 

125  RSEC 

56  K 

17.8  J£EC 

142  «SEC 

19. 2K 

52.1  JJSEC 

416.6  NSEC 

FULL  DUPLEX 

EVENTS  OCCUR  TWICE  AS  OFTEN, 

OF  COURSE 

1 


l 

tSS&iiH 


DESCRIPTION 

The  2652  Mui! • Protocol  Communications 
Controller  MPCO  >s  a monoMh'C  n- 
c hann^i  MOSLSU'fCuit  that  formats  trans- 
mits j"d  'ece-.^s  synchronous  serial  data 
«n,ie  support-ng  o>t  or  ented  or  byte  con- 
trol protocols  The  cn»p  s TTL.  compatible 
operates  from  a single  -5V  supply  and  can 
interface  to  a processor  witn  an  8 or  16-bit 
bidirectional  data  bus 

FEATURES 

• DC  lo  500 k bps  data  rata 

• Protocol  management 

Sit-oriented  protocols  (BOP):  SDLC, 
AOCCP.  HDLC 

Byte-control  protocols  (BCP):  BI-SYNC. 
DOCMP 

• Programmable  oparatlon 

8 or  IS-bn  (rl-stata  data  but 
Protocol  salacllon— BOP  or  BCP 
Error  control— CRC  or  VRC  ornoarror 
chacti 

Charactaf  length — 1 to  I bits  lor  BOP 

o/  5 lo  I bits  for  BCP 

SYNC  or  secondary  station  address 

comparison  lor  BCP-BOP 

idia  trsnsmitsion  of  SYNC  FLAG  of 

MARK  I of  BCP-BOP 


• Automatic  dalaction  and  generation  ol 
spaoal  BOP  control  sequences.  I a.. 
FLAG.  ABORT.  GA 

• Zaro  msarlion  and  dalalion  lor  BOP 

• Short  character  dalaction  lor  laet  BOP 
data  characlar 

• SYNC  ganarallon,  dalaction,  and  strip- 
ping lor  BCP 

• Maintenance  Mode  lor  sell- lasting 

• Common  parsmatar  control  registers 

• Independent  status  and  data  registers  lor 
receive  and  transmit 

• Status  indicator  signals  can  ba  used  aa 
CPU  Interrupts 

• TTL  compatible 

• 40-pin  package 

• Single  ♦ 5V  supply 

APPLICATIONS 

• Intelligent  terminals 

• Una  controllers 

• Network  processors 

• Front  end  communlcatlona 

• Remote  data  concentractor* 

• Communication  last  equipment 

• Computer  to  computer  links 


PIN  CONFIGURATION 


sigmitics 


3 


p 


( 


< 


l 
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COM  5025 

/LPC  FAMILY 

Preliminary  Specifications 

Multi-Protocol 

Universal  Synchronous  Receiver/Transmitter 

USYNR/T 


FEATURES 

□ Selectable  Protocol — Bit  or  Byte  oriented 

□ Direct  TTL  Compatibility 

□ Tri-state  Input/Output  Bus 

□ Processor  Compatible — 8 or  1 6 bit 

□ High  Speed  Operation — 2.0M  Baud — typical 

C Fully  Double  Buffered — Data,  Status,  and  Control  Registers 

□ Full  or  Half  Duplex  Operation — independent  Transmitter  and 

Receiver  Clocks 
— individually  selectable  data 
length  for  Receiver  and 
Transmitter 

C Master  Reset — resets  all  Data,  Status,  and  Control  Registers 


BYTE  ORIENTED  PROTOCOLS— BiSync,  DOCMP 

□ Automatic  detection  and  generation  ot  SYNC  characters 

SELECTABLE  OPTIONS: 

Q Variable  Length  Data— t to  8 bit  bytes 
O Variable  SYNC  character— 5.  6.  7,  or  8 bits 

□ Error  Checking — CRC(CRC16  CCITT-O.  orCClTT-1) 

— VRC  (odd  even  parity) 

—None 

□ Strip  Sync — deletion  of  leading  SYNC  characters  after 

synchronization 

□ Idle  Mode — idle  SYNC  characters  or  MARK  the  line 


□ Maintenance  Select — built-in  self  checking 


BIT  ORIENTED  PROTOCOLS—  SDLC,  HDLC,  ADCCP 

~ Automatic  bit  stuffing  and  stripping 
C Automatic  frame  character  detection  and  generation 

□ Valid  message  protection — a valid  received  message  is 

protected  from  overrun 

C Residue  Handling— for  messages  which  terminate  with  a 
partial  data  byte,  the  number  of  valid 
data  bits  is  available 

SELECTABLE  OPTIONS. 

V Variable  Length  Data— i to  8 bit  bytes 
m Error  Checking— CRC  (CRC 1 6.  CCITT-O.  or  CCITT- 1 ) 
—None 

■ Primary  or  Secondary  Station  Address  Mode 
C All  Parties  Address— APA 

■ Extendable  Address  Field — to  any  number  of  bytes 
• Extendable  Control  Field— to  2 bytes 

□ Idle  Mode — idle  FLAG  characters  or  MARK  the  line 
E Point  to  Point.  Multi-drop,  or  Loop  Configuration 


PIN  CONFIGURATION 


Voo  C 

1 

40 

2 MSEl 

*cpQ 

7 

39 

3 tcp 

RSiQ 

3 

31 

2 tso 

vr  Q 

4 

37 

2 t*e*a 

REACT  C 
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34 
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no*  r 
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2 T0Mt 

«SaC 
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] Tract 
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APPLICATIONS 


n Computer  to  Modem  Interface 

□ Modem  to  Computer  Interface 

□ Terminal  to  Modem  Interface 

□ Modem  to  Terminal  Interface 


□ Peripheral  to  Modem  Interface 

□ Modem  to  Peripheral  Interface 

□ Serial  Data  Bus 


APPENDIX  VIII 
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INDUSTRIAL  PROCESS  COMPUTER  INTER- SUBSYSTEM 


COMMUNICATION 
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(JAPAN- 2) 
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SICS  - JEIDA 
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IMPLEMENTATION 
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COMMITTEEE 


STANDARDIZATION  OF  INDUSTRIAL  COMPUTER  SYSTEMS 
(JEIDA- JAPAN  ELECTRONIC  INDUSTRY  DEVELOPMENT  ASSOCIATION) 

SICS-JEIDA 

Scope  of  work 
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1.  INTRODUCTION’ 

The  intention  of  this  document  is  to  describe  a standard  inter- 
subsystem  communication  method  in  order  to  increase  the  degree  of 
compatibility  between  subsystems  from  various  manufacturers,  thus 
enabling  them  to  be  used  together  in  more  complete  computer  based 
process  measurement  and  control  systems. 

1.1  OBJECTS  OF  PROPOSED  GUIDELINE 

(1)  This  proposed  guideline  applies  to  information  interchange 
systems  used  to  interconnect  both  process  control  and  pro- 


cess computer  apparatus  with  other  apparatus  and  accessories 
necessary  to  assemble  instrumentation  and  control  system 
including  computer  systems. 

(2)  This  proposed  guideline  describes  the  design  concepts  and 
the  specifications  for  implementation  of  industrial  process 
computer  inter-subsystem  communication  (hereafter  it  is 
called  Ii dustrial  dataway  system) . 

(3)  A primary  focus  of  this  document  is  to  set  forth  a 
conceptual  design  guideline  of  industrial  dataway  system. 

(This  document  deals  only  with  reference  for  standardizing 
promotion  of  Industrial  dataway  system) . 

1.2  SCOPE  OF  GUIDELINE  (STANDARDIZATION) 

(1)  The  goal  of  this  guideline  (standardization  is  to  recommend 
main  features  of  digital  data  communication  using  bit  serial 
techniques  over  single  line  sharing  system. 

(2)  This  data  communication  system  (Industrial  dataway  system) 

is  capable  of  supporting  centralized  intelligence,  distributed 
intelligence,  hierarchical  intelligence  and  combinations 


thereof.  In  particular,  It  .shall  be  capable  el  supper 1 1 tip, 
distributed  systems  for  process  measurement  and  control. 

( 1)  This  guideline  deals  only  with  the  communication  Interface 

characteristics  el  Industrial  dntawav  system  to  the  exclusion 
of  network  control  and  application  functions,  and  design 
spec  1 1 (cat  ion  of  electrical  signal  i it  communicat ion  line. 

(•'<)  This  guideline  does  net  take  aim  at  the  optimal  interface 

for  high  speed  standard  computer  with  high  speed  periphctals, 
such  as  mass  memories,  line  printers  and  se  on . Also,  it 
Is  net  Intended  let  ellicienl  sharing  el  mass  storage  and 
peripherals  between  processors. 

CO  This  guide  lint1  is  Intended; 

to  define  a genera  I “purpose  svstem  for  use  in  long 
distance  cotnmun lea S ion  application  (max  50  km  straight 
1 I no) . 

to  spec i I v the  device  independent  lunetienal,  electrical 
and  mechanical  Interlace  t o<|tt i foment s which  devices  and/or 
stations  shall  meet  In  ordet  I o he  Interconnected  and 
communicate  unambiguous  I v via  I tie  system. 

to  enable  the  int  creonnoot  ion  el  Independently  mat  af act ured 
dev  1 ccs  Inti'  I he  ••  st  cm . 

MATT liHS  ltlsl.ATKI)  TO  TIIK  TTNCT1 ONAI.  KKiJll  1 UT.NT.NTS 

(I)  This  guideline  Is  based  on  I lie  "Oral  t el  Functional  Kegii  l fo- 
ments lor  I lulnst  t la  I ITocoss  Computet  I nt  etMibsv.sl  em 
Ceinmnnicat  Ion"  I KC  SC  n'tA/WCh  (Secretary)  11  which  is  ptep.tied 
at  I / 7 - I IS  and  ISA  SI' 7 7 (Seetel.u  v)  S which  is  p repined 


at  IP//  1 I A. 
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(2)  The  devlat  Ions  between  tills  gu  Ide  I I no  and  tin'  I'nnc t Iona 1 
Requirements  ( 1 KC*  SC  (iSA/WC  b anil  ISA  SI*  7 1* ) atr  shown  In 
Append  I x S. 

APPLICATION  KNV I KONMKNTS 

2.1  REVIEW  OF  DATA  COMMUNICATION 

(1)  The  line  sharing  systems  tor  Industrial  plants  are  developed 
and  utilized  In  various  types  ot  systems  shown  In  Figure-l 
and  Table-1. 

(2)  The  existing  line  sharing  system  was  designed  as  the  above 
requirements,  so  there  were  many  kinds  of  line  sharing  system 
that  provided  for  the  different  grade  of  each  requirements. 

(a)  Volume  for  data  transmission,  and  required  throughput. 

(h)  Quick  response  In  data  transmission,  and  required 

priority  interrupt  handling. 

(r)  Distance  for  data  transmission. 

(d)  Connected  devices  in  data  transmission  network. 

(e)  Intelligence  for  data  communication  support  at 
connected  device,  device  interface,  or  communication 
interface. 

(f)  Reliability  and  Maintennhi 1 i tv . 

(g)  Economies,  reducing  system  costs. 

(3)  The  industrial  process  computer  inter-subsystem  communications 
systems  of  TEC  SC  65A/WC6  will  be  applied  for  inter-computer 
or  intelligent  terminal  communication  for  distributed  com- 
puter control  systems  including  process  data  gathering, 
control  or  supervisory  logic  processing,  man-machine  communi- 
cation supporting  and  other  related  intelligence. 


;» 
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For  this  purpose,  the  Industrial  dataway  system  shown  in 
Figure- 1 seems  to  be  suitable  for  data  communications  in 
process  data  acquisition  and  control. 

2.2  APPLICABLE  FIELD  OF  INDUSTRIAL  DATAWAY  SYSTEM 

2.2.1  OUTLINE 

(1)  The  Industrial  dataway  system  for  on-line  real  time  computer 
control  system  or  distributed  digital  control  system  to  be 
used  primarily,  but  not  exclusively,  in  the  process  industries 
(for  their  continuous  and  discrete  processes). 

(2)  The  following  conditions  should  be  included. 

- to  provide  reliable  and  economic  data  communication 

- to  be  capable  of  being  incorporated  with  in  centralized 
and  distributed  network  control  system 

i o he  capable  of  keeping  ultimate  correct  data  communication 
under  industrial  process  environments. 

( 1)  It  is  required  to  simpl  ify  the  system  assemble,  maintenance 
and  training  of  engineer  and  staff. 

Specifically  it  is  wanted  to  avoid  getting  involved  with  a 
proliferation  of  different  types  of  equipments. 

2.2. 2 TYP I CAL  INDl/STR  r KS 

(1)  This  guideline  applied  generally  to  process  data  acquisition 
and  control. 

This  Industrial  dataway  system  is  intended  to  apply  a closed 
loop  control  system  ot  industries. 

(2)  Typical  application  areas  are: 

] 

- Distributed  digital  control  system 

j 

I 
I 


- Process  computet  control  system 
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For  cxamp 1 e : 

"Industries  which  manufacture  agricultural  and  industrial 
chemicals;  biologicals  and  pharmaceuticals;  elastomers; 
foods,  paints,  varnishes  and  pigments;  petrochemicals  and 
petroleum  products;  pulp  and  paper;  soaps,  glycerin,  and 
detergents;  glass;  cement;  synthetics,  such  as  films  and 
fibers;  and  other  associated  and  related  materials;  anil 
refine  and  produce  metals  and  generate  electric  power.  Such 
processing,  may  involve  a change  In  composition,  shape,  in- 
state of  matter  which  may  be  affected  by  pressure,  tempera- 
ture, chemical  reaction,  mixing,  separation." 

2.2.3  TYPICAL  CONFICUP.ATION 

(1)  The.  overall  configuration  of  Industrial  dataway  system  is 
to  provide  an  effective  communication  link  over  which 
messages  and  commands  are  carried  in  an  unambiguous  way 
among  a group  of  interconnected  devices. 

(2)  The  data  transmission  has  the  capability  to  transport  data 
from  one  station  to  another.  In  data  communication  link, 
the  master  station  due  to  control  of  a link  during  a given 
transmission . 

The  slave  station  dues  to  receive  only  during  a given 
transmission. 

(3)  Master/Slave  status  may  be  changeable.  But  at  any  given  time, 
master  station  has  responsibility  for  link  control  and  error 
recovery  during  transmission. 


4 . 


i 


(4)  The  data  communications  are  carried  among  subsystems  of  the 
following  types: 


LIMITATION  OF  COMPUTER  SYSTEM 


DISTANCE 


Figure-2  Typical  Configuration 


(a)  Single  branch 


(a) 
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Process  signal  Input,  output,  ami  control  subsystems 

(b)  Man/Machine  Interfaces  and  Product  Tdent 1 float  Ion 
Device  Subsystems 

(c)  Supervisory  computer  systems 

(d)  Service,  support  and  maintenance 

(e)  Combinations  of  any  or  all  of  above. 

(5)  The  translator  equipment  will  be  available  which  make  it 
possible  to  Implement  portions  of  the  communication  subsystem 
with  common  carrier  channels. 

(6)  Typical  configurations  are  shown  in  Figure-2. 

3.  FUNCTIONAL  SPECIFICATION 

3.1  TOPOLOGY  OF  INDUSTRIAL  DATAWAY  SYSTEM 

(1)  The  Industrial  dataway  system  is  required  to  support 
distributed  system  for  process  data  acquisition  and  control, 
and  field  expandability. 

The  topology  of  Industrial  dataway  system  is  recommended  as 
branch  type. 

(2)  In  this  industrial  dataway  system,  single  line  shared 
communication  is  applied.  In  single  line,  data,  control 
frame  and  synchronization  signal  should  be  included. 

(3)  In  more  reliable  system,  loop  type  or  redundancy  like  dual 
or  duplex  system  shall  be  applied. 

(4)  This  system  is  not  intended  to  handle  message  switching. 

Note:  Typical  examples  are  shown  in  Appendix-1  and  2 

respectively. 
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3.2  MASTERSHIP  IN  INDUSTRIAL  DAT AWAY  SYSTEM 

(1)  The  master  station  which  currently  controls  the  link  is 
given  to  any  station  as  multi  mastership. 

(2)  Address  and  its  related  modifier  shall  be  specified  to  be 
applicable  for  n:n  corresponded  communication 

(3)  The  available  architectures  of  the  communications  should  not 
preclude  direct  data  interchange  between  any  two  stations: 

It  should  be  possible  to  transmit  data  direct  between  any 
two  subsystems  on  the  link  without  necessarily  involving 
store  and  forward  at  a third  subsystem. 

3.3  TRANSMISSION  SPEED 

(1)  The  industrial  dataway  system  will  be  optimized  for  a 
raw  bit  rate  of  1 MBPS  or  more. 

3.4  TRANSMISSION  DISTANCE 

The  industrial  dataway  system  should  be  capable  of  accommodating 

two  class  ol  distance,  to  achieve  hi  and  applicability. 

(1)  Remote  sites  accessible  over  leased  lines  with  repeaters: 
Maximum  50  km  (straight  line) 

(2)  Between  any  two  stations:  Maximum  4 km  (without  repeaters) 

3.5  NUMBERS  OF  STATIONS  PER  DATAWAY 

(1)  The  Industrial  dataway  system  shall  be  capable  of  having 
stations  per  one  dataway: 


(a) 

Ml  ni  nu  mi 

31 

stat  i oils 

(b) 

Up  to 

255 

stat ions 

1.6  NUMBERS  OF  DEVICES  PER  STATION 

(1)  The  Industrial  dataway  system  shall  be  capable  of  having 
following  devices  per  one  station: 


I 


< 


-613- 


(a)  Process  Input/output  subsystem  : max.  512  pts. 

(in  case  of  ana  lop,  input) 

(h)  Process  controller  : max.  128  pts. 

(in  case  of  3 mode  controller) 

(c)  Terminal  device  : max.  16  pts. 

(in  case  of  device  subsystem) 

3.7  TYPE  OF  DEVICE 

Devices  to  be  connected  with  station  are  shown  in  Appendix-3. 

[See  2.2.3.  (*»)] 

3.8  MODE  OF  TRANSMISSION 

Bit  serial  technique  is  applied  to  this  system.  And  also  half- 
duplex transmission  is  good  for  this  application,  because  of  high 
transmission  speed. 

3.9  PRIORITY  CONTROL  OF  TRANSMISSION 

(1)  Asynchronous  signals  or  events  shall  be  served  within  a 
definite  interval  that  is  short  time  interval  to  ignore  an 
effect  on  delay  of  asynchronous  events. 

(2)  The  communication  system  shall  be  served  without  delay  when 
a local  devices  or  terminals  have  errors  or  troubles. 

(3)  Priority  control  down  by  hardware  may  not  be  necessary  in 
case  of  satisfaction  of  the  above  mentioned  requirements. 

3.10  RESPONSE  TIME 

Detection  of  asynchronous  signals  or  events  shall  be  served  less 
than  20  msec. 

3.11  MODULATION  AND  SYNCHRONIZATION 

Modulation  technique  for  the  industrial  dataway  system  shall  be 
enough  to  apply  base-band. 
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Synchronization  should  be  bused  on  HDLC's  definition. 

3.12  TYPE  OF  COUPLING 

(1)  The  Industrial  dataway  system  shall  be  easy  for  installation 
and  maintenance,  so  that  coupling  of  signal  line  of  dataway 
should  be  standardized  as  follows: 

1)  Coaxial  cable  : T-connector 

2)  Twisted-pair  cable  : Terminal  strip 

3.13  EXPANDABILITY 

(1)  The  Industrial  dataway  system  shall  provide  flexibility  for 
the  user  to  economically  change  or  expand  the  system  after 
installation  within  practicable  address  areas  and  distance 
lira! tat  ions. 

(2)  The  Industrial  dataway  system  can  lie  extended  or  stations 
or  devices  added.  Such  changes  may  disturb  the  exchange  of 
messages  as  a transient  effect,  provided  that  the  system  is 
able  to  detect  such  disturbances  and  recover  full  operation 
within  a time  appropriate  to  the  application. 

1.14  ENVIRONMENTAL  CONDITION 

The  Industrial  dataway  system  is  used  for  applications  of  process 
Indus t ties . 

Environmental  condition  of  this  system  is  recommondab 1 e as  follows: 

1)  Operating  temperature  range  : 0 to  50  C 

(Do  not  include  terminal  device) 

2)  Operating  humidity  : below  95%  (without  dew) 

3)  Earth  potential  : less  than  10  ohms* 

4)  Withstand  boltage  : AC  1,500V  1 min. 


(for  power  line) 


XSfcJi 


■ _ 
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tion orotoco! 


Communication 
link  protocol 

Physical 

interlace 

Physical  link 
nrotocol 


Station 
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Figure-5  System  structure  of  the  Industrial 
da t away  system 


a,.  1 . 
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DC  500V  1 min . 

(for  signal  line) 

Note:  *)  The  system  must  he  able  to  function  normally  with 

extreme  static  and  dynamic  differences  of  ground 
potential  between  two  stations  on  the  link. 

A.  ARCHITECTURE 

A . 1 SYSTEM  STRUCTURE 

The  Industrial  dataway  system  is  structured  into  five  functional 
levels  with  respect  to  data  transmission  shown  in  Figure-3. 

These  five  levels  include: 

(1)  Physical  link 

(2)  Communication  link 
(5)  Logical  connection 
(A)  Network  control 

(5)  Application  (Devices) 

The  functions  and  protocols  of  each  level  are  described  in 
Section  5. 

A. 2 FRAME  STRUCTURE 

The  UDLC's  lormat  shall  be  adopted  as  the  frame  structure  of 
message  for  data  transmission  is  the  Industrial  dataway  system. 
The  UDLC’s  format  is 


I 
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(1)  F:  Flag  Held  (8  hits) 
F field  designates  the 
the  hit  structure  of 

0 13  11110 


(2)  DA:  Destination  address  (8  hits) 

DA  field  contains  the  destination  address  of  the  station  to 
be  received  message. 

(3)  C:  Control  field  (8  bits) 

C field  defines  type  of  control  (ex.  command /reply) 
depending  on  the  bit  structure  of  this  field. 

(4)  SA:  Source  address  (8  bits) 

Basically,  SA  field  contains  the  source  station  address  of 
the  message.  This  field  is  necessary  for  data  transmission 
on  the  n:n  corresponded  communication. 

(3)  I:  Information 

I field  consists  of  Header,  Control  status,  Device  address, 
Test  (data)  and  so  on.  Length  of  this  field  is  varied  upon 
amount  of  data  to  be  transferred. 

(6)  FCS:  Frame  check  sequence  (16  bits) 

Each  message  contains  the  FCS  field  for  the  purpose  of 
detecting  transmission  error. 

It  is  recommendable  that  checking  is  based  on  CRC. 

5.  PROTOCOL 


The  allocation  of  specific  functional  requirements  for  protocols  is 
defined  as  follows: 


AD-A058  096 


UNCLASSIFIED 
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5.1  PHYSICAL  LINK  PROTOCOL 


The  detailed  requirements  of  a physical  link  protocol  are  dependent 
on  link  or  line  physics  and  must  be  transparent  to  and  independent 
of  the  message  bit  stream  including  communication  link  addresses, 
checking  codes,  etc. 

If  message  frame  delimiters  are  dependent  on  line  physics,  they 
must  be  added  and  subtracted  by  the  line  coupling  unit.  (For 
example,  the  Modem  in  FSK  carrier  situations.) 

Typical  of  existing  standards  of  this  protocol  are: 

(1)  C C I T T V.24  (RIA  RS-232) 

(2)  C C I T T X . 21 

( !)  2()niA  current  loop 

The  physical  interface  is  characterized  in  terms  as  follows: 

(1)  The  transmission  data  rate  of  1 M bps  or  more. 

(2)  Bit  synchronization. 

(3)  Clock  extraction  (Bit  element  timing). 

(4)  Base-band  transmission. 

(5)  Electrical  isolation  from  transmission  signal  line. 

(6)  Redundant  (Dual  or  Duplex)  data  transmission  paths  should 
be  optional. 

(7)  Bypassing  and  disconnect  capability. 

5.2  COMMUNICATION  LINK  PROTOCOL 

The  communication  protocol  is  specific  to  the  communication 
subsystem  but  is  independent  of  the  signalling  techniques  employed 
in  the  physical  communication  link.  This  protocol  is  also 
independent  of  the  characteristics  of  the  stations  attached  to 


the  communication  subsystem. 


The  Common  lent  Ion  Mnk  Protocol  of  Industrial  Hat  away  System 
should  bo  organized  on  the  basis  of  ISO  IIDLC  and  character  1 zed 
In  terms  ns  follows: 

(1)  n:n  ( or  n:m)  comnumirnt Ion  capability. 

(2)  Frame  structuring  based  on  the  HDLC  to  transmit 
unformatted  binary  data  (data  tr*»nsparency) . 

(3)  Transmission  error  detection  by  CRO. 

(4)  Error  recovery  by  automatic  retransmissions.  No-response 
timer  and  retransmission  counter  are  required  to  prevent 
from  unduly  delay  other  messages. 

(5)  More  than  one  communication  subsystems  should  he 
responsible  to  recover  from  the  disappearance  of 
current  master. 

(6)  Broadcasting  command  Is  required  to  transmit  global 
messages  to  all  subsystems. 

(7)  Initialization  capability  of  communication  subsystems. 

5.3  LOGICAL  CONNECTION  PROTOCOL 

This  layer  has  to  do  with  the  synchronization  of  the  transmit  and 
the  receiving  hardware  on  both  sides.  Since  this  hardware  attaches 
to  the  processor  channel  I/O  interface,  a function  must  exist  in 
the  hardware  to  reflect  to  the  processor  a logical  channel  rend/ 
write  interface. 

(1)  Thi9  level  shall  provide  arbitration  between  the  message 
length  capabilities  of  the  communication  subsystem  and  the 
message  length  requirements  at  the  application  level. 

Examples  are  rejection  or  blocking  and  deblocking  of  messages 
which  exceed  the  message  length  capabilities  of  the  communi- 
cation subsystem. 


(')  Es  tab  It  alt  and  release  logical  data  chamwln. 

t 0 Watch  Dor  Timor  to  recover  from  hang-up  »'l  l.oglcal  Connect  (on. 
(4)  1 1*1  capability  lor  distributed  Intelligence. 

SAFETY  AND  SRCl'RITY 

t..l  TRANSMISSION  ERROR  PROCESS  INC 

The  Imlustrial  dataway  system  shall  be  capable  ot  supportinp. 
tan  It  diagnosing  capability. 

This  capability  Is  class! tied  into  two  caleRories.  One  shall  be 
1 ne  I tided  In  Industrial  dataway  system  and  the  other  shall  be 
.supported  by  outside  scope  ot  Industrial  dataway  system  tisclt. 

I'he  termer  might  include  as  follows: 

(I)  Error  control  by  us  I iir  CKO  check  I hr  and  automatic  retrial 
1 unc t i oils 

t.')  Sense  status  of  all  station 
('1  Monitoring  response  time  interval 

(4)  Shift  the  frame  svnelu  on  i :•  i tig  station  or  clock  unit  in 
case  ol  I a I I ure 

( '> ) ('ot  root  loti  lot  lop  ol  synchros  I :\tt  Ion 
tli)  Data  sequence  check  inp. 

The  I a t tel  as  foil ows : 

(I)  Code  and  address  error  cheeking 

(.’)  Centralized  supervisory  for  all  station  and  communication 
line  operation 

(1)  Test  oi  diagnostics  lot  all  stations  under  on-line  operation 
The  Industrial  dntawav  system  shall  lit'  capable  oi  maintaining 
correct  sequencing  anti  Integritv  of  transmitted  data  through  an 


electrically  noisy  env I t onment . 


The  etti'i  detection  scheme  must 


and  errors  delecting,  sell  loop  checking  and  Isolating  ttom 
«c  1 1 ve  commtin  I ca t ( <>i>  link. 

(2)  Manual  station  bypassing  from  active  conuntin  teat  Ion  link 
without  any  system  disturbance  or  error. 

(3)  Re-organ  lent  ion  of  comnuintcut ion  link 
(sell  link  configuration) 

(4)  Kxtenslve  use  ol  so  1 1 check t ng  software  should  provide  tel  table 
supervision  with  possibility  t o locate  and  diagnose  potential 
system  errors. 

b.  ' OTIIKRS 

(1)  System  expansion  and  modification  under  on-line  operation 
of  data  communications. 

(2)  The  communication  subsystem  shall  include  optional  versions 
which  will  survive  lightning  strifes  or  power  faults  on  the 
transmission  medium  and  will  prevent  the  equipment  connected 
to  the  subsystem  from  becoming  hazardous  when  these  conditions 
occur . 

(1)  The  communication  subsystem  shall  meet  the  relevant  mandatory 
standards  of  licensing  agencies. 

(4)  The  communication  subsystem  shall  include  optional  versions 
for  which  Intrinsic  safety  certification  can  he  obtained. 

(I)  Pasv  to  make  dual  staltons  or  dual  power  supply  units. 
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((')  Reliable  transmission  cable  way  system  including  dual 

cabling,  protection  tor  disconnection  and  clamp,  and  noise 
protection  for  transmission  signal. 

(7)  The  physical  Implementation  of  the  interface  within  the 
subsystem  should  be  designed  so  that  the  subsystem  is 
isolated  and  may  perform  electronic  state  transitions  such 
as  on-line/off-line,  povcr-on/powor-of f , ready/not  ready, 
busy /not  busy,  loon  1 /remote , etc.  without  generating 
transmission  errors  between  other  subsystems. 

MA 1 NTT.NANt'l 

7.1  ON  1.1  NT  MAlNTKNANC.b 

til  The  communication  subsystem  shall  he  capable  ot  supporting 
on-line  testing  and  fault  diagnosing  capability. 

This  might  include  traffic  monitoring  and  on-line  and 
remote  loopback  test  facilities.  There  features  are  not 
integral  functions  ol  the  communications  subsystem. 

7..’  0KK-I.1NK  MA!  NTKNANt'K 

fl)  Maintenance  panel  shall  he  connected  to  the  station  lor 
test  ot  diagnostics  under  oft  line  mode. 


I 


ac  1 1 ve  common  teat  1 on  link 

address 

appl teat  ton 


base  band 
bit  serial 
branch 

broadcasting  command 

clock  extraction 
clock  unit 
command 

common  carrier  channel 
common  t ca  t t on  1 1 no 
communication  link 
communication  subsystem 
communicat ion  system 
control  frame 


data  communication 

data  sequence  check 
data  transmission 
data  transmission  path 
data  transparency 
destination  address 

device 


device  interface 


frame 

frame  check  sequence 
field 


Sect  ion 


3.2  (2),  6.1  (1),  6.1  (3) 

4.1 


1.2  (1),  3.8 

3.1  (1),  Figure-.? 

5.2  (6) 


b . 1 (4) 

2.2.  J (1) 

2.2.1  (3) 

1.2  (1).  h.l  (?) 

2.2.  I (1).  4.1,  7.2  ( 1) 
2.2.  1 (3).  h.l,  7.1 

1.2  (2),  3.9  (2) 

3.1  (2) 


1.2  (2),  2.1,  2.2.1  (2). 

2.2.3  (4).  6.3  (1) 

6.1  (?) 

2.1  (2),  2.2.3  (2).  4.1,  4. 


3.2  (2) 

4.2  (2) 

1.2  (3),  2.1  (2),  2.2.3  (1) 
3.6.  3.7,  3.13  (2) 

2.1  (2) 


4.2  (1) 

3.1  (2).  4.2 

4.2  (6) 


Terras 


Section 


(G) 

► ■ — -■  - — 

global  message 

5.2  (6) 

(H) 

header  control  status 

4.2  (5) 

(I) 

Industrial  Dataway  System 
information 

4.2  (5) 

(L) 

line  coupling  unit 

• * 

5.1 

line  physics 

5.1 

line  sharing  system 

2.1  (1),  2.1  (2) 

link 

2.2.3  (1),  3.2  (1),  3.2  (3), 
4.1,  5.1 

link  control 

2.2.3  (3) 

logical  channel 

5.3 

logical  connection 

4.1,  5.3  (3) 

loop 

3.1  (3),  Figure- 2 

(K) 

master 

2.2.3  (3) 

mastershi p 

3.2 

master  station 

2.2.3  (2),  2.2.3  (3),  3.2  (1) 

message 

2.2.3  (1),  A. 2 

message  blocking 

5.3  (1) 

message  deblocking 

5.3  (1) 

message  switching 

3.1  (4) 

multi-mastership 

3.2  (1) 

(N) 

network  control 

1.2  (3),  2.2.1  (2),  A . 1 

n:n  corresponded  communication 

3.2  (2),  A. 2 (A) 

(0) 

of f- 1 lne 

6.1  (3).  6.3  (1),  6.3  (7), 

7.  1 

on  1 1 ne 

6.3  (7),  7.2  (1) 

(P) 

physical  Interface 

5.1 

physical  link 

A . 1 

protocol 

Figure-3,  5 

Terms 


Section 


(R) 

receiving 

5.  3 

remote  loopback 

7.1  (l) 

repeater 

3. A (1).  3. A (2) 

(S) 

self  loop  checking 

b.2  (1) 

signal  line 

3.12  (1) 

single  line  sharing 

1.2  Cl),  3.1  (2) 

slave 

2.2.3  (3) 

slave  station 

2.2.3  (2) 

source  address 

A. 2 (A) 

station 

2.2.3  (2).  3.2  (1).  3.2  (3). 

3. A (2).  3.5,  3.6,  3.7, 

3.13  (2) 

station  bypassing 

6.2  (1),  6.2  (2) 

subsystem 

1,  2.2.3  (2),  3.6,  3.2  (3) 

6.3  (2),  6.3  (7) 

synchronization 

3.11,  6.1  (5) 

synchronization  signal 

3.1  (5),  3.1  (2) 

(T) 

text 

4.2  (5) 

t ransmisslon 

6.3  (6),  2.2.3  (2).  2.2.3  (3) 

transmit 

i 

5.3 

m*  -*v  m ■ i 
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APPENDIX- 1 

TYPICAL  IMPLEMENTATION  IN  CASE  OK  CENTUM  F-BUS 

APPENDIX- 2 

TYPICAL  IMPLEMENTATION  IN  CASE  OK  T0SWAY-1500 

APPENDIX- I 

TYPE  OF  DEVICES  TO  BE  CONNECTED  INDUSTRIAL 
DAT AWAY  SYSTEM 

APPENDIX-4 

LAYER  OF  PROTOCOL 

APPENDIX- 5 


DEVIATION  BETWEEN  FUNCTIONAL  REQUIREMENTS 
AND  PROPOSED  GUIDELINE  (JAPAN) 


SS3E  "iskb;  • 


BMD9E 
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APPENPIX- 1 


TYPICAI.  I MPI.EMENTAT ION 
IN  CASE  OF 
CENTUM  F-BUS 


April  23,  ] 977 


Based  on  the  proposed  guideline. 


1.  FUNCTIONAL  SPEC1  FICTION 


3.1  TOPOLOGY  OF  CENTO'  E-Bl'S 


The  F-BUS,  which  is  a component  of  all  CENTUM  systems,  allows 
data  to  he  transferred  around  the  control  system  at  a 250K  bps 
rate . 

it  incorporates  coaxial  cables,  coupler  units,  branch  units, 
repeaters,  power  supplies  and  communication  controllers. 

It  can  be  up  to  10  kilometers  long,  and  can  be  connected  through 
computer  adapters  to  virtually  any  computer  having  data  communica- 
tion capabilities.  (Ktg.-l) 

CENTUM  F-BUS  has  a branch  type  configuration,  and  each  station 
is  connected  to  coaxial  cable  with  passive  (transformer)  coupler. 
3.2  MASTERSHIP  IN  CENTUM  F-BUS 

(1)  Based  on  the  proposed  guideline. 

Mastership  is  sent  and  received  one  after  another  by 
"Baton  Pass"  command. 

(2)  Based  on  the  proposed  guideline. 

The  communication  command  frame  and  response  frame  have  not 
only  destination  address  but  also  source  address. 

( 0 Based  on  the  proposed  guideline. 

1. I TRANSMISSION  SPKEU 


2S0K  bps 
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5.4  TRANSMISSION  DISTANCE 

lip  t>  .’Kin  wltliuut  repent  era 
Up  to  lOKin  us  1 up.  repon tors 
1.3  NUMBKR  OF  STATIONS  PER  DAT AW AY 
Up  to  10  ststl ons 
3.()  TYPE  OF  DEVICE 

(1)  Ann  lop  inputs  and  outputs 
(.’)  Digital  Inputs  and  outputs 
(1)  Process  controllers 

(4)  Operator’s  console  (CRT  aiul  keyboard) 

(*>)  Auk.  memory 
(t>)  Typewi  i ( ci 
(/)  Computer 
1./  MODE  OF  TRANSMISSION 

tilt  serial  and  lmlf-duplex  transmission  by  lime  division 

1.8  PRIORITY  CONTROL  OF  TRANSMISSION 

The  transmission  priority  Is  controlled  by  well  assigned 
"Hat  on  Pass"  sequence 

1.9  RESPONSE  TIME 

Rased  on  t lie  proposed  guideline 
Typical  msec 

1.1(1  MODULATION  AND  SYNCHRONIZATION 
Rase-baud  t i an  sin  I ss  ion 

Synch  i mi  I :m  I I on  Is  based  on  IIDl.C'n  del  inti  Ion 
1.11  TYPE  OF  COUP  I,  I flC 

Coaxial  cables  (SOU) 

The  station  Is  connected  through  slp.nal  transformer  and  connector. 


! 


1 


AC  100  V.  M 'MHi 


1.1.’  EXPANDAB  I l.l  TY 

llosod  on  tin1  pi  oposed  pn  I do  1 I no 
l.l  I KNV 1 RONMENTAL  CONDITION 


(1) 

Opel  at  1 li )*. 

t empei  at  lire 

o i o so  <: 

(?) 

Opera  I i up. 

bum  Kl  1 1 v 

40  to  DOT.  Itll 
tNo  eondensat Ion) 

(3) 

Ground  1 up 

(Earth) 

less  than 

1 0 ohms 

(A) 

W i t hs  t and 

SC 

> 

for  power  lint* 

AC  1 KV, 

1 m i n . 

for  s 

lgnal  line 

DC  500V, 

1 min. 

4.  ARCHITECTURE 

4.1  SYSTEM  STRUCTURE 

From  tilt'  viewpoint  of  cotnraun  icat  ion,  stations  are  classified  into 
the  primary  stations  anti  the  secondary  stations.  The  primary 
station  is  a station  havinp,  the  initiative  o(  common  I oat  ion. 
Communication  is  comlncteil  by  a command  frame  from  the  primary 
station  anti  a response  frame  from  the  secondary  station. 
Communication  on  t lit'  F-Bus  Is  conducted  on  a single  coaxial  cable 
which  conveys  a command  frame  a ml  a response  I tame  one  aftei 
another.  Kip,.-?  illustrates  the  wav  of  common (cation. 

t . 1 FRAME  STRUCTURE 


SYNC 
8 SITS 


LCW  1 


LCW 


" fctST 
8 BITS 


C 

8 B I T£ 


' orit’E 

8 sirs 


mpTy 

8 BITS 


DATA 

FCS 

UP  TO  100 8 BITS 

16  BITS 

(1) 

SYNC 

(2) 

LCW  1 , 2 

(3) 

DF.ST 

(A) 

C 

(5) 

SRCE 

(f>) 

MDFY 

(7) 

DATA 

(8) 

FCS 

SYNCHRONOUS  Fl.AC,  0 I 1 1 1 1 I 0 
I. INK  CONTROL  WORD 
DESTINATION  ADDRESS 
CONTROL  ( COMMAND / R ES PON S E ) 

SOURCE  ADDRESS 
MODIFIER 
MESSAGE  DATA 

Message  Data  has  variable  length  of  up  to  1 (108 
bits,  and  16  hit  (1  word)  increment. 

FRAME  CHECKING  SEQUENCE 

FCS  is  the  lb  bit  CRC  of  x'*’  + X 1 ‘ + x"'  + l 


f 


-T' 
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PROTOCOL 

There  are  4 levels  of  protocol  for  the  CENTL'M  F-BUS, 

(1)  Physical  link  protocol 

(2)  Commumcat.  ion  link  protocol 

(3)  Logical  connection  protocol 

(4)  Application  protocol 

These  protocols  are  implemented  in  F-BUS  as  Fig. -4. 


Application  protocol 

Logical  connection 
protocol 

Communication  link 
protocol 


Physical  link 
protocol 


Coaxial  cable 


Fig. -4  Layers  of  protocol  in  F-BUS 


1 


-636- 

5.2  COMMUNICATION  LINK  PROTOCOL 

5.2.1  CONTROL  PROCEDURES 

The  F-3US  has  the  Primary /Secondary  protocol. 

The  Primary  station  is  responsible  for  control  of  the 
link,  including  initialization,  organ ization  of  data 
transfer,  and  link  error  recovery. 

Secondary  stations  are  responsible  only  for  performing 
operations,  as  instructed  by  the  Primary. 

The  I*r irary  station  sends  a command  frame  via  the  physical 
link,  and  the  Secondary  station,  selected  by  the  destina- 
tion address  field  of  the  command  frame,  set. is  back  a 
response  frame,  in  the  manner  of  half-duplex  mode  trans- 
mission. 

A communication  link  is  completed  by  a pair  of  command  and 
response . 

Primary  and  Secondary  station  assignments  will  be  changed 
dynamically  by  the  Baton  sequence,  being  different  from 
HDLC's  proceudre. 

The  Primary  station,  which  has  the  Baton,  is  the  current 
master  of  communication. 


i 

I 


5.2.2  COMMAND  AND  RESPONSE 

The  set  of  Commands  and  Responses  are  defined  in  Table* 1 

COMMAND 


CONTROL  BITS 
C0  C1  c2  Cj>  c4  c5  c6  c7 


0 

0 

1 

1 

0 

0 

0 

0 

1 

1 

1 

0 

0 

0 

1 

1 

1 

1 

0 

1 

1 

1 

0 

0 

0 

1 

1 

1 

1 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

0 

1 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

WORD  COUNT 
*ORD  COUNT 


| WORD  COUNT 


RESPONSE 


CONTROL  BITS 
C0  CX  C 2 C?  C4  Cc,  C-p 


OOOOOl 
0 1110  0 


: .'.ORD  COUNT 

; word  coj-.t 

! WORD  COUNT 


MNEMONIC 


POL/STS 


COMMAND 


Buffer  Read 
Read 
Write 
Enquire 

Poll/Sense  Station  Status 
Initialize  Reset 
Raton  Fass 

Reset  Broadcast  Reject 
Initial  Procram  Load 
Broadcast  Reject 
Send 

Ex  chanr>' 

( Command  Ex t ens i on ) 


MNEMONIC 


RESPONSE 


CA  Command  Accept 

CRT  Command  Retransmission  Request 

IC  Invalid  Command 

RB3  Receive  Buffer  Busy 

BRR  Buffer  Read  Reject 

MNR  ‘Memory  No  Response 

MPE  Memory  Parity  Error 

CNR  CPU  No  Response 

ACK  i Acknowledge 

NAK  J Negative  Acknowledge 

EXR  ! (Response  Extension) 


Table-1  Commands  and  Responses 


(2)  Command  Error  Recovery  Procedure 


Secondary 


Pr  unary 


Command 


Command 

(.'transmission 


Fa \ lure 


Same  as  non-error  procedur' 


Retransmission  Count 
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■>.3  LOO  I CM.  CONNECTION  PROTOCOL 

To  control  and  exehanp.e  various  data  between  stations, 
lias  lor.  leal  procedures  as  follows. 

( 1 ) Send 

(2)  Send  Sequence 

(3)  Send  and  Receive 

(4)  Send  and  Receive  Sequence 

(5)  Send  Wait  and  Receive 

(6)  Send  Wait  and  Receive  Sequence 

(7)  Rend 

(8)  Read  Sequence 

( 9 ) Write 

(10)  Write  Sequence 

(11)  1 PL 

(12)  PollinR  and  Buffer  Read 

(13)  Status  Sense 

(14)  Initialize  Reset 

(15)  Baton  Pass 

(16)  Broadcast  Reject 

(17)  Broadcast  Send 

(18)  Broadcast  Send  Sequence 

(19)  Broadcast  Initialize  Reset 


f it  1 1 


SAFETY  AND  SECURITY 


(!)  Error  detection  by  CRC  atui  parity  check,  and  error  recovery 
bv  automatic  retransmission  procedures. 

(J)  Duplicated  transmission  paths. 

(3)  Localization  of  the  failed  station  bv  automatic  and  manual 
d i sconnec t ion . 

(A)  No  active  elements  (i.c.  1C,  transistor)  on  the  transmission 
line,  except  for  repeaters  and  branch  units. 

(5)  Non-cen t ru 1 i zed  multi-master  stations. 

uAl NT E NANCE 

(I)  System  maintenance  panel  for  system  supervision. 

(.’)  Remote  tPL  (Initial  Program  Load)  function. 

(3)  Remote  restart  function. 

(4)  Remote  saving  the  program  of  failed  stations,  making  easv 
to  analyze  the  causes  of  failure. 

(5)  Transmission  signal  level  monitoring. 


TYPICAL  IMPLEMENTATION 
IN  CASE  OF 
TOSWAY  - 1500 


April  23,  1977 


» 1 
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I.  INTRODUCTION 

Bast'd  on  proposed  pul  del  1 nr. 

APPLICATION  KNVIKONMKNTS 
Based  on  proposed  guideline. 

).  FUNCTIONAL  SPECIFICATION 

1.1  TOPOLOGY  OF  TOSWAY-1 500 

(1)  TOSWAY- 1500  lias  a loop  configuration  to  provitle  the 
reliable  ilalaway  system.  (I' Ip.  1-a) 

(.')  TOSWAY • 1 ')()(>  consists  of  two  t i ansmi  salon  lines,  one 
loi  data  transmission  and  anothei  lor  lost  signal  In 
notmal  data  transmission.  In  case  ot  abnoimal  condition 
sncli  as  dop.i  ada  t I ons  ol  l lie  station,  these  two  lines 
make  I lie  let  m n path  at  the  both  sides  ol  the  dep,  railed 
station  and  disconnect  It  t torn  the  svstom  to  prevent 
the  entire  system  I rotn  not  of-soived  condition. 

(Ftp.  l-b.c) 

(1)  TOSWAY-1 500  is  not  Intended  to  handle  message  switching. 

1.2  MASTFRSII I P In  TOSWAY- I'iOO 
(I)  Sat Isf led. 

('.!)  Sat  1st  I ed  . 

( I)  Sal  1st  led. 

i.  I TRANSMISSION  SI’F.F.D 
I , *>44  M bps 


TI'ANSM  1 S,‘ 

; i on 

1)1  STANCH 

(1) 

1(10 

Km 

with  repealer 

(.’) 

4 

Km 

w 1 t hunt  repeat  or 
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!-S>h^-45>-i>>4 


rrf>HS 


7<h  <1  !';<]- 

I J I 


Kig.  l-t> 


Data  Tran.-.raission  in 
Normal  Condition 
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I.S  Nl’MUKR  OK  STATION  t'KR  OAT  AWAY 


Max.  12  stations 


' . 6 NI'MBKK  OK  DKVICK  I’KK  STATION 


(I)  Process  input/ output  subsystem  : Max.  s09('  pts. 


(in  case  of  analog  input) 


(2)  Process  controller 


; Max.  128  pis 


(in  case  ol  1 mode  controller) 


( 1)  Tot  m i na  1 ilov  i ce 


: Max.  lt>  sets 


(in  case  ol  device  subsystem) 


1.7  TYI’K  OK  OKYU'K 


(I)  Ana  lop.  Input 
(,’)  Digital  Input 

(II  Oip,ital  Output  (Incltidinp,  analog  output) 


(•i>  Teimtna!  Itevic 


foiiiput  el 


I'.n  <1  i eailei 


Paper  tape  rondel 
To  I opr  i lit  et 

CRT  (fat  hod  Kav  Tube)  display 


1.8  MOOT.  OK  TRANSMISSION 


( 1 ) n:t  serial  tocbni<|iie  is  applied 
('1  Halt  duplex  t t ansm I ss ion  is  adopto 


I."  I’ll  I OK  I IN  fONTKOl,  01  TRANSMISSION 


l.  10  KKSI’ONSK  T1MK 


Sal  t s I I ed . 
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1.11  MODULATION  AND  DEMODULATION 

(1)  Base-band  is  applied  as  modulation  tocbnl(|uo 
(?)  Synchronization  is  based  on  IIDLC's  definition 
1.1?  TYPE  OF  COUPLING 

Twisted-pair  cable  Is  used  for  signal  line,  so  that  terminal  1 
strip  is  adopted  as  coupling  of  signal  line 

3.13  EXPANDABILITY 

(1)  Satisfied 

(2)  Satisfied 

3.14  ENVIRONMENTAL  CONDITION 


(1) 

Operating  temperature  range 

0 to  50°C 

(?) 

Operating  humidity 

below  95* 

(w  1 1 flout 

(3) 

Shock 

less  than 
at  10  to 

0. 150 

50  11/ 

(4) 

Earth  potential 

less  than 

10  ohm 

(r»)  Withstand  voltage 

for  power  line  AC  1500  V,  1 min. 

for  signal  line  DC  500  V,  1 min. 

4.  ARCHITECTURE 

4.1  SYSTEM  STRUCTURE 

T0SWAY-1500  is  structured  into  five  functional  levels  with  respect 
to  data  transmission.  (Fig. -3) 

These  five  levels  Include: 

in  TOSWAY-1 500 

(1)  Physical  link  REP  (Repeater) 

(2)  Communication  link  DLC  (Data  link  controller) 

(3)  Logical  connect  ton  «•--►  STC  (Station  terminal  controller) 

(4)  Network  contro l-^-^  Network  control 

(5)  Application  (Devices)  Application  (Devices) 


r 


Fig. -3  Syste: 


(1)  F:  Flag  field  (8  bits) 

F field  designates  the  start  and  end  of  the  frame  and  has 
the  bit  structure  of 
0 1 I 1 1 I 1 0 

(2)  DA:  Destination  address  (8  bits) 

DA  field  contains  the  address  of  the  station  to  he 
received  the  message. 

(3)  C:  Control  field  (8  bits) 

C field  defines  type  of  control  (ex.  command/reply) 
depending  on  the  bit  structure  of  this  field. 

(4)  LV:  Priority  level  field  (8  bits) 

LV  field  decides  transmission  order  of  messages  in 
accordance  with  processing  priorities  of  them. 

(5)  SA:  Source  address  (8  bits) 

SA  field  contains  the  source  station  address  of  the 
message. 

(6)  I:  Information  field 

I field  consists  of  Header,  Control  status.  Device  address, 
Texts  (data)  and  etc.  Length  of  this  field  is  varied 
upon  amount  of  data  to  be  transferred. 


1 


_ 


. * - rjsrxw 


- 

!j 
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(7)  FCS : Frame  check  sequence  field  (16  bits) 

Fach  message  contains  the  FCS  field  for  the  purpose  of 
detecting  transmission  error. 

Checking  adopted  in  TOSWAY-1500  is  based  on  CRC. 

PROTOCOL 

5.1  PHYSICAL  LINK  PROTOCOL 

Interface  (in  STC)  can  be  coupled  to: 


(1) 

f CIT  T V . 24  standard 

dev ices 

(2) 

C ('ITT  X.21  standard 

dev i ces 

(3) 

20mA  current  loop 

(A) 

TOSBAC-40  series  computer 

0>) 

Devices  which  are  coupled 

to  TOSBAC 

The  physical  interface  of  TOSWAY- 1 500  is  based  on  that  of 
proposed  guideline. 

(1)  The  transmission  data  rate:  1,544  MBPS 

(2)  Bit  synchronization 

(3)  Clock  extraction  (Bit  element  timing) 

(4)  Base-band  transmission 

(5)  electrical  isolation  from  transmission  signal  line 

(6)  Redundant  (Dual  or  Duplex)  data  transmission  paths 
should  be  optional 

(7)  Bypassing  and  disconnect  capability 
5.2  COMMUNICATION  LINK  PROTOCOL 

Communication  link  protocol  of  T0SWAY-1500  is  based  on 
proposed  guideline. 


(1)  n:n  communication  capability 
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(2)  Frame  structuring  based  on  tin*  HD1.C  to  transmit 
unformatted  binary  data  (data  transparency) 

(3)  Transmission  error  detection  by  CRC 

(A)  Error  recovery  by  automatic  retransmissions 

No-response  timer  and  retransmission  counter  are  required 
to  prevent  from  unduly  delay  other  messages 
(5)  More  than  one  communication  subsystems  should  be 
responsible  to  recover  from  the  disappearance  of 
current  master 

(b)  Transmitting  global  messages  to  all  subsystems 
(7)  Initialization  capability  of  communication  subsystems 
5.3  LOGICAL  CONNECTION  PROTOCOL 

Logical  connection  protocol  of  TOSWAY-1500  is  based  on 
proposed  guideline. 

(1)  Establish  and  release  logical  data  channels 

(2)  Watch  Dog  Timer  to  recover  from  hand-up  of  Logical 
Connection 

(3)  I PL  Capability  for  distributed  intelligence 

6.  SAFETY  AND  SECURITY 

6.1  TRANSMISSION  ERROR  PROCESSING 

TOSWAY-1500  is  capable  of  supporting  fault  diagnosing  capability. 
This  capability  is  classified  into  two  categories.  One  is 
included  in  TOSWAY-1500,  and  the  other  is  supported  by  outside 
scope  of  TOSWAY-1500. 

(F.x.  processor  coupled  to  TOSWAY-1500) 


1)  The  former  capability  is  as  follows: 

(1)  Krror  control  by  using  CRC  checking  and  automatic 
retrial  functions 
(?)  Sense  status  of  all  station 
(1)  Monitoring  response  time  interval 

(4)  Shift  the  frame  synchronizing  station  or  clock  unit 
in  case  of  failure 

(5)  Correction  for  log  of  synchronization 
(t>)  Data  sequence  checking 

2)  The  latter  as  follows: 

(1)  Code  and  address  error  checking 

(2)  Centralized  supervisory  for  all  station  and  communication 
line  operation 

(1)  Test  or  diagnostics  for  all  stations  under  on-line  operation 

0.2  SYSTEM  FAILURE  DKTECT10N , PROTECTION  AND  RECOVERY 

(1)  Automatic  remote  station  bypassing  by  using  automatic 
troubles  and  errors  detecting,  self  loop  checking  and 
isolating  from  active  communication  loop 
(?)  Manual  station  bypassing  t rum  active  communication  link 
without  anv  system  disturbance  or  error 
(1)  Re- organ  i .-.a  t i on  ot  communication  link 
(sell  link  configuration) 

b . I OTHERS 

(1)  Satisfied 

(?)  Arrestor  equip,'. 


13)  JIS 
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(4)  None 

(5)  Duplex  station  is  optional  version 

(6)  Dual  cabling  is  standard  version 

(7)  Satisfied 

7.  MAINTENANCE 

7.1  ON-LINE  MAINTENANCE 
(1)  Satisfied 

7.2  OFF-LINE  MAINTENANCE 


(1) 


Sat isf led 
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1)  TOSWAV- 1 SOO  Efficiency  Calculation 
Formula  of  Information  Transmission 


.')  For  Example 


where,  SDN  : BUSY/READY  ENQUIRE  (5  BYTES) 

ACK  : SDN  ACKNOWLEDGE  (5  BYTES) 

IF  : INFORMATION  FRAME  (N  «■  8 BYTES) 

RRl  : IF  RECEIVED  ACKNOWLEDGE  (5  BYTES) 

B : BYTE 

TURN  around  delay 

Translate  at  Bytes  No.  10  BYTES 

The  efficiency  of  information  transmission  is 

Veff  = T(  PB} 

t = SDM  *•  ACK  <•  IF  RR^  ♦ J x T (TURN  around  delay) 
* ♦ N BYTES 

P : Bit  error  probability 

d = 1-P 

PB  * 0 


n - 100  BYTES 


transmission  reception 


Veff  = *f(  o'  ♦ PB> 

= 1-P  P : BIT  Error  Probability 

I r 100  BYTES 

t s 45  ♦ I « 1^5  byte 

if  pb  = 0, 


- 6 'j  8 - 


Al'I’l'.NOt  X I I'YI'i  UK  MYICKS  TO  HI'.  t'.ONNKCTKD 
I Nl'UMTK  1AI.  PATAWAY  SYSTI M 

Hu-  I mins  1 1 I ,i  I d.itnwnv  system  nt e reipi  I foil  nmonp  devices  ol  I lie  followlup, 
l vpos : 

(n)  Input  . i>ut|uit  nml  control  devices 
Koi  example,  devlees  for : 

Analog  Inputs  with  mul  without  spec  ini  signal  ootid  i t ion  I tip . 

Iilpit. il  Inputs  wltli  mil  without  change  ol  stole  not  1 1 lent  ttm . 

Ann  1 op  out pu I 
P I p I I n I on  t put 

Scanning,  nml  unnlvticnl  I list  ruir.cnt  Into  laces 
t'omli  I no  t I ons  ol  tho  nhove 

Comhltiit  Ions  ol  tho  nhovo  inolmllnp  oonliol  nml  mn  I nt  emniee 
loplo,  nlpotlihms  nml  ilntn  stompo 
Oist  I (hut  oil  illp.lt.il  oontrol  svstoni. 
ihl  M.m/Vui'h  l in-  Intoit.ioos  nml  I'loilmt  llovfoos 
For  example: 

H.ulpo  \ m.ipnot  lc  stripe  rviulors 
l.nhol  renders 
To  I opt'  I lit  oi  s 

Single  onrd  i imiIoi  s Mm  l>  souse  A punohod 

Video  tormln.iln 

Ch.il. ictoi  A line  dlsplnvs 

Kovho.ilds  A hovpnds,  etc. 

pod  I ent  oil  nml/or  spec  In  I pm  pose  oiii  d punches 


I, .the  I , t leket  nml  spoolnl  I ol  m pi  Intel's 


Note:  These  devices  are  recommendable  to  have  standard  interface 
such  as  EIA  RS232C  interface,  20mA  current  loop  and  others. 
These  standards  are  suitable  for  standardization  of  Network 
control  protocol. 

(c)  Supervisory  computers  which  control  and  interrogate  devices 

described  in  3.6.1,  3.6.2  and  3. 6. A.  These  computers  may  exchange 
large  blocks  of  data  and/or  programs  with  the  other  subsystems  on 
an  Infrequent  basis. 


(d)  Service,  support  and  maintenance  equipment 

(e)  Combinations  of  any  or  all  of  the  above 


A dd 


APPENDIX  TX 


PAPERS  OF  THE 

INDUSTRIAL  REAL-TIME  FORTRAN  COMMITTEE 


Documents  included  here  are  as  follows: 

1.  Caro,  R.  H.  Draft  of  S61. 3 

2.  Maliszewski,  Kazimierz , "New  Subroutines  Proposed  for 
RT- FORTRAN." 
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1.0  SCOPE 


This  standard  presents  external  procedure  references  for  use  in 
industrial  conputer  control  systess.  These  external  procedure 
references  provide  leans  for  task  intercossunication  and 
cooperation  through  the  orderly  lanagesent  of  independent  task 
execution.  The  tasks  are  expected  to  be  running  in  a aulti- 
tasking  or  a aulti-processing  environment.  These  procedures 
usually  will  pass  the  intonation  necessary  for  this  orderly 
sanagesent  to  an  executive  routine  which  will  ensure  the  correct 
operation  of  industrial  cosputer  control  systes.  The  nethod  for 
ensuring  orderly  nanageaent  is  left  to  the  processor. 

The  procedure  references  in  this  standard  are  intended  to  provide 
sethods  by  which  the  task  can  infora  the  processor  of  the 
relationships  between  the  task  and  other  independent  tasks  under 
the  control  of  the  saae  processor.  The  standard  provides  the 
seans  to  integrate  independent  tasks  into  a systes  of  cooperating 
tasks  when  used  in  conjunction  with  sound  progras  design  but  the 
isplesentation  of  this  standard  is  no  assurance  that  probleas  of 
non-cooperation  will  not  arise. 

1.1  DEFINITIONS 


limAL-££2££S£OR 

A virtual  processor  is  an  environaent  in  which  an  executable 
prograa  can  run  and  in  which  all  the  resources  needed  for  the 
execution  of  the  executable  prograa  are  always  available.  A 
particular  iapleaentation  serves  to  aap  the  set  of  virtual 
processors  on  to  the  actual  processor.  This  aapping  aay  be 
controlled  by  an  executive  routine  and  is  processor  dependent. 
The  virtual  processor  exists  only  when  the  set  of  pending 
executives  is  not  eapty,  or  when  an  executable  prograa  is  in 
either  the  state  Voluntary  Suspend  on  the  state  Running. 

CICI>I£_«KflIIOg 

Cyclic  execution  is  a set  of  executions  of  an  executable  prograa 
by  its  virtual  processor. 

imiu 

The  coaputing  language  defined  as  full  FORTRAN  ISO  R1539-1972 
which  is  the  saae  as  American  National  Standard  FORTRAN  ANSI  X3.9- 

1 *s*  6 . 

A aode  of  operation  that  provides  for  the  interleaved  execution  of 
two  as  lore  computer  programs  by  a single  processor. 


flg«I-eBg£E35IBS* 


A aode  of  operation  that  provides  for  parallel  processing 
or  aore  processors  of  a suit i- processor. 


fRBCKOUO  pjob 


. A. 
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mu=nsms* 

A Multiple  operation  that  provides  for  the  concurrent  performance 
or  interleaved  execution  of  two  or  aore  tasks. 

PROCESSOR* 

In  a computer  a functional  unit  that  interprets  and  executes 
instructions. 

IkSZ 

The  execution  of  an  executable  prograa.  The  ISO/DIS  2382/1 
definition  of  a task  is  more  general,  "A  basic  Unit  of  work  to  be 
accomplished  by  a computer".  In  this  standard  the  basic  unit  of 
work  is  restricted  to  an  executable  program. 

5I£££IA£Ii£_£&2G£AH 

A program  in  a fora  suitable  for  execution. 

I££££M£II!I_1A£E 

A task  whose  existence  at  any  time  is  independent  of  the  existence 
of  any  other  task. 

A task  whose  existence  is  dependent  on  the  existence  of  another 
task. 

£X£U£-£X£££!I£JL0V£££0£ 

Cyclic  execution  overrun  occurs  when  a task  is  a set  of  cyclic 
executions  of  a prograa  and  the  start  of  the  execution  of  a 
program  is  to  occur  before  the  completion  of  the  previous 
execution  of  the  program.  A cyclic  execution  overrun  is  an 
occurrence  within  a real  processor.  Note  that  a cyclic  execution 
overrun  can  occur  in  a real  processor  when  it  will  not  occur  in 
the  tasks  virtual  processor. 


* Definitions  taken  from  ISO/DIS  2382/X 
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1.2  BACKGROUND  INFORMATION 

In  a computing  systea  Individual  tasks  aay  have  various 
relationships. 

—Tasks  can  be  independent 

— Tasks  can  be  independent  but  interrelated 

— Tasks  can  be  dependent 

Industrial  systeas  usually  consist  of  independent  but  interrelated 
tasks  and  in  these  systeas  the  tasks  can  have  various  features 
such  as: 

--Tasks  can  be  initiated  either  at  a specified  tine  or  by  an 
event  and  such  initiation  can  be  carried  out  repetitively. 

— Tasks  can  be  initiated  to  be  coaplete  by  a specified  tine. 
This  is  frequently  called  deadline  scheduling. 

— Tasks  can  be  synchronized  to  clock  tiae  or  with  process 
events. 

— Initiation  can  be  deferred  depending  on  tiae  or  event. 

— Tasks  can  be  suspended  voluntarily  or  involuntarily. 

— Tasks  can  be  terainated  through  noraal  coapletion  or 
through  unforseen  exception  conditions. 

--Tasks  aay  share  inforaation. 

— Tasks  aay  send  aessages  to  other  tasks. 

— Tasks  can  terainate  other  tasks. 

--Tasks  can  suspend  other  tasks. 

— Tasks  can  be  resuaed  after  suspension 

— Tasks  aay  set,  clear  or  test  event  indicators. 

— Tasks  aay  obtain  unique  control  of  a shared  resource. 
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1.3  TASK  FEATURES  INCLUDED  IN  THIS  STANDARD 

In  industrial  computer  system s,  tasks  are  independent  but 
interrelated.  This  standard  does  not  address  all  the  areas  of 
independent  tasks  interrelationships  but  is  concerned  with  those 
features  that  most  commonly  arise  in  industrial  computer  systems. 

Table  I shows  those  features  covered  by  the  standard  and  those 
excluded;  however,  the  excluded  features  may  affect  the  result  of 
a request  for  cooperation  from  one  independent  task  to  another. 
Such  restrictions  are  processor-dependent  and  outside  the  scope  of 
this  standard. 


TABLE  I 


INCLUDBD 

Indpendent  but  interrelated  tasks 
Initiation  at  a given  time,  upon  event, 
after  a period  or  repetitively 
Suspension  of  a task  by  itself 
Resumption  of  a task  by  another  task 
Resumption  of  a task  by  an  event, 
at  a given  time  or  after  a period 
Termination  by  a task  of  another  task  or  itself 
Set t ing/clea ring/testing  of  event  conditions 


Dependent  tasks 

Process-dependent  exception  conditions  such  as 
overflow/underflow 
Task  suspension  by  another  task 
Suspensions  caused  by  the  processor 
Suspensions  caused  by  the  executive  routine 
All  methods  of  sharing  variables  or  arrays 
All  methods  of  sharing  files 
Sending  messages  between  tasks 
Termination  of  tasks  based  on  events  in  the 
executive  routine 

All  other  functions  of  the  executive 
Deadline  scheduling  of  tasks 
Boolean  operations  on  events 
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2.  STATES  OF  A TASK 


A task  can  exist  in  four  states  which  define  the  operation  of  the 
task.  All  procedure  references  concerned  with  task 
interrelationships  involve  the  change  of  a task  from  one  state  to 
another  state. 

The  states  of  a task  are  defined  in  terns  of  a task's  virtual 
processor.  A virtual  processor  is  defined  in  Section  1.1.  A 
virtual  processor  has  all  of  it's  resources  always  available  for 
the  execution  of  the  task.  The  executive  performs  the  necessary 
napping  of  a set  of  virtual  processors  onto  the  actual  processors. 

The  aechanisn  used  for  this  napping  is  processor  dependent. 
Included  in  the  resources  necessary  for  task  execution  are:  nemory 
space,  central  processor (s)  tine,  and  general  conputer  peripheral 
availability.  The  napping  of  the  virtual  processors  onto  the  real 
processor  frequently  iaplies  that  the  time  for  a task  to  execute 
to  completion  in  its  virtual  processor  is  less  than  the  time  for 
the  sane  task  to  execute  to  completion  in  the  real  processor. 
Thus  the  napping  of  the  virtual  processors  onto  the  real  processor 
is  a measure  of  system  loading  which  is  clearly  both  system  design 
dependent  and  processor  dependent. 

Each  separate  initiation  of  a task  creates  a new  virtual 
processor.  Each  such  virtual  processor  is  identifiable  to  the 
executive  program  and  the  mechanism  for  identification  is 
processor  dependent.  A cylic  or  repetitive  initiation  of  a task 
by  a single  procedure  reference  has  only  one  virtual  processor  for 
all  the  repetitive  executions  of  the  task  and  is  identifiable  as  a 
single  entity  to  the  executive  program. 

A diagram  of  the  states  is  shown  in  Figure  1. 

The  definition  of  task  interrelationships  in  terms  of  virtual 
processors  does  not  imply  that  a particular  implementation  must 
include  the  concept  of  a virtual  processor  or  require  a virtual 
storage  executive  routine,  but  the  particular  implementation  must 
ensure  that  the  result  of  an  execution  of  a reference  to  the 
subroutine  procedures  given  in  Section  i»,  follow  the  definitions 
in  that  section. 

A task  can  change  the  state  of  any  other  task  except  that  a task 
can  only  be  changed  from  Running  to  Voluntary  Suspend  by  itself. 

2.  1 Task  State  Definitions 

The  four  states  of  a task  are  Non-existent,  Pending,  Running,  and 
Voluntary  Suspension  defined  as  follows: 

2.1.1  Non-existent . The  task's  virtual  processor  does  not  exist  and 
the  real  processor  is  unaware  of  the  existence  of  the  task. 
However,  the  executable  program,  whose  execution  would  become  the 
task,  can  and  usually  does  exist  and  the  executable  programs 
existence  is  usually  known  to  the  processor. 


dp  S6 1 . J 
JAN  197H 


A ♦ ♦ 

1 I 

| RUNNING  | 

>1  I 

B ♦ ♦ 


1 

A A 

1 

1 1 

1 

♦ 

-♦  | E 

1 E 

1 

1 

1 

1 

♦ - 

-♦ 

1 

C| 

1 

i 

1 

1 

I PENDING 

i 

1 

1 

1 

i 

1 

1 

-♦ 

1 

1 

1 

A 

1 

1 

Gl 

m 

1 

1 

1 

i 

NON-EXISTENT  | 

1 

1 

i 

V 

1 

Y 

i 

------------- 

| VOLUNTARY  |< 
| SUSPEND  | 

I I- 

♦ ♦ 


E 


I 

f 


Eiqure  1 

TASK  STATE  DIAGKAN 

A)  DELAY,  NATT,  NAITE 

B)  occurrence  of  t ho  event  or  completion  of  the  tine  period 

C)  SKED,  START,  THNON  for  innediate  execution  or  CON  nhere 
the  event  has  already  occurred 

n)  SEED,  START,  TR NON , CON,  CYCLE 
E)  ABORT,  STOr 

E)  occurrence  of  the  event  or  tine 
(?)  DSKED,  DCON,  DCYCLB 
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2.1.2  EfiBiiBS*  The  task’s  virtual  processor  exists  and  the  task  is 
awaiting  the  occurrence  of  an  event  to  begin  execution  at  which 
occurrence  the  task  will  wove  to  the  state  Running.  The  real 
processor  aay  or  nay  not  have  loaded  the  task  into  its  aeaory  but 
the  task  is  known  and  identifiable  to  the  real  processor.  The 
■echanisas  for  this  identification  are  processor  dependent. 

2.1.3  EllAHing*  The  task’s  virtual  processor  exists  and  the  task  is 
running  in  its  virtual  processor.  At  any  time  the  task  aay  or  nay 
not  be  running  in  the  real  processor  depending  on  the  sapping 
procedure  of  the  virtual  processors  onto  the  real  processor.  The 
■echanisas  for  this  napping  are  processor  dependent. 

2.1.4  l2laBiatI-_3i!§l>£!!SiOB-  The  task’s  virtual  processor  exists  and 
task  is  suspended  in  its  virtual  processor  awaiting  the  occunence 
of  an  event  to  resuae  execution  at  which  occurrence  the  task  will 
aove  to  the  state  Running. 

3.  EVENTHARIt  S 

In  the  aanageaent  of  independent  interrelated  tasks,  there  are 
nuierous  requirements  to  key  actions  to  the  occurrence  of  events. 
The  aechanisa  chosen  to  enable  such  action  is  the 

Eventaarks  are  integer  counters  supported  by  the  executive  program 
which  aust  be  non-negative.  An  event  is  noted  by  incrementing  a 
specific  eventaark  by  one  (1)  which  action  is  called  "setting"  the 
eventaark.  The  eventaark  is  decremented  by  one  (1)  by  direct 
program  control  or  by  the  execution  of  a task  which  was  keyed  to 
the  occurrence  of  the  event  noted  by  the  eventaark.  This  action 
is  called  "clearing"  the  eventaark.  Eventaarks  can  only  be 
changed  by  the  procedure  references  defined  in  this  standard  and 
by  the  executive  routine. 

If  an  eventaark  is  defined  as  zero  (0)  in  a procedure  reference, 
no  action  will  be  taken  and  the  execution  routine  will  ignore  any 
actions  dependent  on  that  eventaark. 

3.  1 Eventaark  Handling 

Eventaarks  are  properties  of  the  processor  which  exist  as  only 
zero  or  positive  integer  values  where  zero  aay  be  considered  as 
OFF  and  any  positive  value  is  considered  ON.  Eventaarks  aay  be 
cuaulative,  in  that  they  aay  count  the  number  of  "sets"  thus 
requiring  an  equal  number  of  "clears"  before  the  condition  will 
change.  Once  the  condition  has  been  achieved  no  further 
accumulation  will  occur;  a single  "set"  will  always  establish  an 
ON  condition. 


3.1.1  Setting  an  eventmark  to  the  ON  condition,  SETEN 
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Execution  of  a reference  to  the  subroutine  SETEN  shall  cause  the 
specified  eventmark  to  be  set  to  the  ON  condition.  If  the 
event aark  was  already  ON,  the  accuaulation  of  such  sets  shall  be 
incremented.  Should  the  action  of  SETEN  result  in  a change  of 
state  froa  OFF  to  ON,  any  programs  pending  or  delayed  for  the 
occurrence  of  the  event  will  enter  their  running  state  and  the 
eventaark  will  be  decremented.  The  form  of  the  CALL  is  as 

follows: 

CALL  SETEN  (e,a) 

where: 


e specifies  the  desire  eventmark;  an  integer  expression 

m is  set  on  return  to  the  calling  program  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  argument  shall  be  an  integer  variable  or  integer 
array  element. 

3.1.2  Clearing  an  eventmark,  CLREN 

Execution  of  a reference  to  the  subroutine  CLREN  shall  decrement 
by  one  the  count  of  sets  to  the  specified  eventmark.  If  the 
eventmark  was  already  at  OFF,  there  will  be  no  action.  The  fora 
of  the  CALL  is  as  follows: 

CALL  CLREN  (e,m) 

where: 

e specifies  the  desire  eventmark;  an  integer  expression 

m is  set  on  return  to  the  calling  program  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater 

1 - request  accepted 

2 or  qreater  - request  rejected 

This  argument  shall  be  an  integer  variable  or  integer 
array  element. 
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3.1.3  Testing  the  eventaark  condition,  TESTEN 

Execution  of  a reference  to  the  function  TESTEN  shall  return  a 
logical  TRUE  value  if  the  specified  eventaark  was  ON  (set)  and  a 
logical  FALSE  value  if  the  eventaark  was  OFF  (clear).  The 
condition  of  the  eventaark  shall  not  be  affected.  The  fora  of 
this  function  reference  shall  be  as  follows: 


TESTEN  (e,  a) 


where: 


e specifies  the  eventaark,  an  integer  expression 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  aust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  arguaent  shall  be  an  integer  variable  or  integer 
array  eleaent. 

3.1.4  Presetting  an  eventaark  count,  PRESEN 

Execution  of  a reference  to  the  subroutine  PRESEN  will  assign  a 
declared  value  to  the  specified  eventaark.  Should  the  action  of 
PRESEN  result  in  a change  of  state  froa  zero  to  soae  positive 
value,  any  prograas  pending  or  delayed  for  the  occurrence  of  the 
event  will  enter  their  running  state  and  the  eventaark  will  be 
decremented.  The  fora  of  the  call  is  as  follows: 


where: 


CALL  PRESEN  (e,  v,  a) 


specifies  the  eventaark;  an  integer  expression 

specifies  the  desired  preset  value  of  the  eventaark;  an 
integer  expression  which  aust  be  zero  or  positive  in 
value. 
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is  set  on  return  to  the  calling  program  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  must  he  1 or  greater 

1 * reguest  accepted 

2 or  greater  - request  rejected 

This  argument  shall  be  an  integer  variable  or  an  integer 
array  element. 


4.  EXECUTIVE  INTERPACE 

4. 1 Control  of  Task  Execution 

Executive  interfaces  provide  the  facility  to  control  operation  of 
the  tasks  within  the  system.  Through  these  external  procedures, 
one  may  start,  stop,  delay  or  synchronize  the  execution  of  tasks. 

4.1.1  Exception  Handling 

The  argument  m,  shown  below  in  each  of  these  executive  interface 
procedures,  shall  be  set  equal  to  or  greater  than  two  (2)  in  value 
for  all  instances  in  which  the  request  was  not  accepted  by  the 
executive  routine.  Individual  implementations  may  specify  unique 
values  of  m within  the  allowable  range  to  designate  the  specific 
reason  for  which  the  request  was  rejected. 

4.2  Starting  a Task  Immediately  or  After  a Specified  Time  Delay  or 
Upon  an  event  occurrence,  SEED 

Execution  of  a reference  to  the  subroutine  SEED  shall,  after  the 
expiration  of  the  specified  time  delay  or  at  the  desired  time  of 
day  or  upon  the  occurrence  of  a specified  event,  cause  the 

execution  of  the  designated  program.  The  program  thus  scheduled 
becomes  known  as  a task.  The  actual  time  resolution  obtainable  in 
a specific  industrial  computer  system  is  subject  to  the  resolution 

of  that  system's  real  time  clock.  Execution  of  the  designated 

task  will  commence  at  the  program's  first  executable  statement. 
The  task  is  placed  in  the  state  PENDING,  the  task's  virtual 

processor  comes  into  existence  and  the  task  is  known  and 
identifiable  to  the  real  processor.  The  fort  of  this  procedure 
reference  is: 


CALL  SEED  (i , p,  s,  e‘,  t« 


n,  t*,  c,  t3,  e*,  e3,  m) 


a)  an  integer  expression,  or 

b)  an  integer  array  naie,  or 

c)  a procedure  naae 

The  processor  shall  define  which  of  the  above  three 
foras  is  acceptable. 


p specifies  the  task  priority;  an  integer  expression 

s specifies  the  selection  between  event  initiated 
execution  and  tine  dependent  initiation;  an  integer 
expression  evaluated  as  follows: 

“ 1 start  iaaediately 

= 2 start  at  tine  of  day  indicated  by  t* 

* 3 start  when  eventaark  specified  by  e1  becoaes 

ON 

* 4 start  at  tiae  t»  or  when  the  eventaark 

specified  by  e1,  becoaes  ON,  whichever  is 
first 

= 5 start  after  tiae  period  t1  has  expired 

= 6 start  after  tiae  period  tl  or  when  the 

eventaark  specified  by  e*  becoaes  ON, 
whichever  is  first 

e1  specifies  the  eventaark;  an  integer  expression 

t*  designates  an  integer  array  naae  whose  first  eight  (8) 
eleaents  contain  the  tiae  at  which  the  specified  progran 
is  to  be  executed. 

These  eleaents  are  as  follows: 

First  eleaent  - Hours  (0  to  23) 

Second  eleaent  - Minutes  (0  to  59) 


lJ 
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Third  element  - Seconds  (0  to  59) 

Fourth  element  - Billiseconds  (0  to  1000) 

Fifth  element  - basic  units  of  the  system  real  time 
clock . 

Sixth  element  - Day  (1-31) 

Seventh  element  - Month  (1-12) 

Eighth  element  - Year  from  AD  0 


n specifies  a time  phasing  by  which  the  starting  time  of 
the  designated  task  would  be  deferred  from  the  time 
stated  in  t*  or  the  event  specified  by  e1 . This 
variable  must  be  an  integer  expression  evaluated  as 
follows: 

=1  no  deferred  start 

= 2 start  at  the  next  occurrence  of  the  time  of 
day  specified  by  t2  after  the  time  or  event 
specified  by  t1  or  e1  depending  on  s,  occurs. 

= 3 start  after  a period  of  time  specified  by  t* 
from  the  occurrence  of  time  t1  or  event  e1 
depending  on  the  value  of  s. 

t2  specifies  the  time  of  day  or  incremented  time  for  the 

deferral  of  the  start  of  a task  as  specified  by  n;  this 
must  be  an  integer  array  name  as  described  in  t* 

c specifies  the  cyclic  execution  of  the  task;  an  integer 

expression  evaluated  as  follows: 

= 1 no  cyclic  execution  (run  once  only) 

= 2 cyclic  execution  each  time  period  as  specified 
in  t3 

» 3 cyclic  execution  each  time  the  eventmark 
specified  by  e2  becomes  ON 

t3  specifies  the  time  period  for  cyclic  execution;  this 

must  be  an  integer  array  name  as  described  in  t» 


e2  specifies  the  eventmark  for  cyclic  execution;  an  integer 
expression . 


1 


f 
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e>  specifies  the  eventnark  to  be  turned  ON  upon  a cyclic 
overrun  condition;  an  integer  expression.  Note:  Cyclic 
execution  overrun  can  only  be  set  by  a cyclic  SEED  (or 
other)  request  with  c = 2 or  3. 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  Bust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  arguaent  shall  be  an  integer  variable  or  integer 
array  eleaent. 


4.2.1  Cause  a prograa  to  cycle  at  a stated  frequency,  CYCLE  (a 
shortened  fora  of  SEED) 

Execution  of  a reference  to  the  subroutine  CYCLE  shall  the 
execution  of  the  designated  prograa  iaaediately  and  cause 
successive  executions  to  occur  after  specified  periods  of  tine. 

The  cyclic  period  is  defined  as  the  period  between  successive 
initiations  of  the  specified  prograa.  Resolution  of  tine  is  as 
always  subject  to  the  linitations  of  the  systea's  real  tine  clock 
and  other  processing  which  nay  be  occurring.  If  a cyclic  overrun 
condition  occurs,  the  action  is  processor  dependent  and  no 
eventaark  is  set.  The  fora  of  this  procedure  reference  is: 

CALL  CYCLE  (i,  p,  t»,  a) 

where:  x 

i specifies  the  prograa  to  be  executed. 

The  arguaent  is  either: 

a)  an  integer  expression,  or 

b)  an  integer  array  naae,  or 

c)  a procedure  naae 

The  processor  shall  define  which  of  the  above  three 
foras  is  acceptable. 


p specifies  the  task  priority;  an  integer  expression. 

The  definition  and  usage  of  this  parameter  is  processor 
dependent . 

t3  specifies  the  cyclic  tine  period;  this  Bust  be  an 

integer  array  naae  as  described  in  t* 

■ is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  aust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  argument  shall  be  an  integer  variable  or  integer 
array  element. 

An  execution  of  a reference  to  CYCLE  would  have  the  saae  effect 

as  a reference  to  SKBD  with  the  following  values  of  the 

regaining  arguaents: 

s =1 

el  =0 

t*  = (don' t care) 
n = 1 

t * * (don*  t care) 
c = 2 
e*  = 0 
e3  = 0 

.2.2  Cause  a prograa  to  execute  each  tiae  a stated  eventaark  becoaes 
OH,  CON 

Execution  of  a reference  to  the  subroutine  CON  shall  cause  the 
designated  prograa  to  becoae  associated  with  the  specified 
eventaark  such  that  the  task  shall  perfora  one  execution  each  tiae 
the  stated  eventaark  changes  froa  OFF  to  ON.  The  task  shall  begin 
froa  the  first  executable  stateaent.  If  a cyclic  overrun 
condition  occurs,  the  action  is  processor  dependent  and  no 
eventaark  is  set.  The  fora  of  this  procedure  reference  is: 
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CALL  CON  (i,  p,  e‘ , ■) 
where: 

i specifies  the  prograa  to  be  executed. 

The  argument  is  either: 

a)  an  integer  expression,  or 

b)  an  integer  array  naae,  or 

c)  a procedure  naae 

p specifies  the  task  priority;  an  integer  expression 

e1  specifies  the  eventaark;  an  integer  expression 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  reguest  as  follows: 

The  value  aust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  arguaent  shall  be  an  integer  variable  or  integer 
array  eleaent. 

An  execution  of  a reference  to  CON  should  have  the  sane  effect  as 
an  execution  of  a reference  to  SKBD  with  the  following  values  of 
the  reaaining  arguaents: 


s 

2 

3 

e* 

s 

0 

t» 

= 

(don't 

care) 

n 

s 

1 

t* 

* 

(don't 

care) 

c 

s 

2 

t* 

= 

(don't 

care) 

e* 

s 

0 
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4.3  Terminating  a Scheduled  Task,  DSKED 

Execution  of  a reference  to  the  subroutine  DSKED  shall  immediately 
disassociate  the  execution  of  the  specified  program  with  either  a 
future  time  or  an  event  or  both.  The  task  associated  with  the 
program  will  be  removed  from  the  state  PENDING  ,the  task's  virtual 
processor  will  become  non-existent  and  the  task  will  become 
unknown  to  the  real  processor.  The  form  of  the  call  is  as 
follows: 

CALL  DSKED  (i,  j , n,  t,  o) 


where : 


i specifies  the  program  name  to  be  descheduled. 

The  argument  is  either: 

a)  an  integer  expression,  or 

b)  an  integer  array  name,  or 

c)  a procedure  name 

The  processor  shall  define  which  of  the  above  three 
forms  is  acceptable. 

j specifies  which  of  several  possible  pending  programs 
identified  by  the  i parameter  shall  be  descheduled; 
an  integer  expression; 

= 1 deschedule  the  next  pending  execution  only;  allow 
others  to  remain  scheduled  (applies  only  to  time 
scheduled  programs) 

= 2 deschedule  all  future  executions  of  the  program 
(applies  to  both  time  and  event  scheduled  programs) 

= 3 deschedule  program  i then  currently  pending  after 
waiting  for  a time  period,  t,  to  pass. 

n specifies  the  choice  of  the  content  of  t as  follows: 


* 1 deschedule 

program  i after 

the 

time 

of  day 

specified  by 

t occurs. 

= 2 deschedule 

program  i after 

the 

time 

period 

specified  by 

t has  elapsed. 

r 


' 


! 

tt 

: 

ijj 

t 
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t designates  an  integer  array  naae  whose  first  eight  (8) 
elements  contain  the  tiae  at  which  the  specified  prograa 
is  to  be  descheduled. 

These  eleaents  are  as  follows: 

First  eleaent  - Hours  (0  to  23) 

Second  eleaent  - Hinutes  (0  to  59) 

Third  eleaent  - Seconds  (0  to  59) 

Fourth  eleaent  - Billiseconds  (0  to  1000) 

Fifth  eleaent  - basic  units  of  the  systea  real  tiae 
clock 

Sixth  eleaent  - Day  (1-31) 

Seventh  eleaent  - Month  (1-12) 

Eighth  eleaent  - Year  froa  AD  0 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  aust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  not  accepted 

i 

This  arguaent  shall  be  an  integer  variable  or  integer 
array  eleaent. 

4.3.1  Cancelling  a task  scheduled  for  future  execution,  CANCEL 

Execution  of  a reference  to  the  subroutine  CANCEL  shall 
iaaediately  reaove  the  specified  task  froa  the  tiae  schedule  of 
pending  executions.  The  fora  of  the  call  is  as  follows: 

CALL  CANCEL  (i,a) 

where: 

i specifies  the  task  to  be  reaoved  froa  the  tiae  schedule. 
The  arguaent  is  either: 


1 "" 11  ..|J ■»  '..■  . u *;'^r 
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a)  an  integer  expression,  or 

b)  an  integer  array  name,  or 

c)  a procedure  name 

The  processor  shall  define  which  of  the  above  three 
forms  is  acceptable. 

a is  set  on  return  to  the  calling  program  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater 

1 - request  accepted 

2 or  greater  - delay  as  specified  has  not  occurred 

This  argument  shall  be  an  integer  variable  or  integer 
array  element. 

Execution  of  a reference  to  CANCEL  shall  have  the  same  effect  as 
an  execution  of  a reference  to  DSKED  with  the  following  values  of 
the  other  arguments: 

1 = 1 

n = 2 

t = 0 for  all  elements 

>*.3.2  Removing  a task  from  cyclic  scheduling,  DCYCLE 

Execution  of  a reference  to  the  subroutine  DCYCLE  shall 
immediately  remove  the  specified  task  from  the  list  of  cyclic  time 
based  executions  but  allows  the  execution  currently  in  the  RUNNING 
State,  if  any,  to  be  completed.  The  form  of  the  call  is  as 
follows: 

CALL  DCYCLE  (i,m) 
where : 

i specifies  the  task  to  be  removed  from  cyclic  scheduling. 
The  argument  is  either: 

a)  an  integer  expression,  or 

b)  an  integer  array,  or 

c)  a procedure  name 

The  processor  shall  specify  which  of  the  above  three 
forms  is  acceptable 
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■ is  set  on  return  to  the  calling  program  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  aust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  argument  shall  be  an  integer  variable  or  integer 
array  eleaent. 

Execution  of  a reference  to  DCYCLE  shall  have  the  saae  effect  as 
an  execution  of  a reference  to  DSKED  with  the  following  values  of 
the  other  arguaents: 

j - 3 

n * 2 

t = 0 for  all  elements 

4.3.3  Reaoval  of  a task  froa  tiae  or  event  based  schedule,  DCON 

Execution  of  a reference  to  the  subroutine  DCON  shall  iaaediately 
reaove  the  specified  task  froa  all  future  scheduled  executions 
and/or  association  with  any  event  occurrence.  The  fora  of  the  call 
is  as  follows: 

CALL  PC  ON  (i,  a) 

where: 

i specifies  the  task  naae  to  be  descheduled. 

The  arguaent  is  either: 

a)  an  integer  expression,  or 

b)  an  integer  array  naae,  or 

c)  a procedure  naae 

The  processor  shall  define  which  of  the  above  three 
foras  is  acceptable. 


(-S.M 
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1 - request  accepted 

2 oj  i/to«ter  - request  not  accepted 
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This  nrguiont  shall  ho  .m  inteqer  variable  or  inteqer 
array  element. 


Elocution  of  a reference  to  DCON  shall  have  the  same  effect  as  an 
elocution  of  a reference  to  DSRND  with  the  followinq  values  of  the 
other  arquaents: 


1 a 2 


t.  * 0 for  all  elements 


4.0  Delay  Execution  of  the  Program,  DELAY 


Execution  of  a reference  to  the  subroutine  DELAY  will  cause 
suspension  ot  the  proqraa  execution  until  the  specified  event 
occurs  or  the  specified  t imo  of  day  or  time  period  has  elapsed. 
Whichever  occurrence  happens  tirst  will  cause  the  proqfaa  to 
resume  execution  at  the  statement  followinq  the  call.  If  the 
proqraa  was  DELAY od  for  an  event  to  occur,  the  value  of  the 
event  nark  will  he  automatically  cleared  prior  to  the  resumption  of 
execution.  The  task  will  be  moved  from  the  state  RUNNING  to  the 
State  Vr)  HI  NT  ARY  SUSPEND.  A task  may  only  delay  itself  and  cannot 
delay  another  task  or  bo  delayed  by  another  task.  The  format  rtf 
t he  call  is : 


1 


CALL  DEI  AY  (s,  t»,  e,  m) 
where : 

s specifies  the  selection  between  event  initiated  end-of- 
delay  and  time  dependent  initiation;  an  integer 
expression  evaluated  as  follows: 

1 - t iio  increment  specified  by  t*  ends  delay 

2 - time  of  day  specified  by  t* 

i - event  specif  i e.i  by  e ends  delay 

<i  whichever  r t me  increment  or  event  occurs  first 
ends  delay 

r>  - whichever  t i me  of  day  or  event  occurs  first 
ends  delay 
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■ is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

t1  designates  an  integer  array  naae  whose  first  eight  (8) 
eleaents  contain  the  tiae  at  which  the  specified  prograa 
is  to  be  executed.  These  eleaents  are  as  follows: 

First  eleaent  - Hours  (0  to  23) 

Second  eleaent  - Ninutes  (0  to  59) 

Third  eleaent  - Seconds  (0  to  59) 

Fourth  eleaent  - Milliseconds  (0  to  1000) 

Fifth  eleaent  - Basic  units  of  the  systea  real  tiae 
clock  Sixth  eleaent  - Day  (1-31) 

Seventh  eleaent  - Month  (1-12) 

Eighth  eleaent  - tear  froa  AD  0 

e specifies  the  ewentaark;  an  integer  expression 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  Bust  be  1 or  greater 

1 - request  accepted 

2 or  greater  - requested  rejected 

This  arguaent  shall  be  an  integer  variable  or  integer 
array  eleaent. 

4.4.1  suspend  execution  of  a prograa  for  event  occurrence,  WAITE 

Execution  of  a reference  to  the  subroutine  WAITE  will  cause 
suspension  of  the  prograa  execution  until  the  specified  event 
occurs.  Following  the  occurrence  of  the  event,  the  prograa  will 
resuae  execution  at  the  stateaent  following  the  call  with  the 
value  of  the  eventaark  autoaat ical ly  cleared.  The  foraat  of  the 
call  is: 

CALL  WAITE  (e,a) 


where: 
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e specifies  the  eventaark;  an  integer  expression 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

1 - request  accepted 

2 or  greater,  request  rejected 

This  argument  shall  be  an  integer  variable  or  integer 
array  eleaent  nane. 

Execution  of  a reference  to  WAITE  shall  have  the  saae  effect  as  an 
execution  of  a reference  to  DELAY  with  the  value  of  S*3  and  no 
particular  value  of  t*. 

4.5  Abort  a Prograa,  ABORT 

Execution  of  a reference  to  the  ABORT  subroutine  will  cause  the 
naaed  prograa  to  immediately  terainate  execution  and  to 
disassociate  itself  froa  all  forms  of  scheduled  activity  whether 
based  upon  event  occurrence  or  time.  The  task  is  reaoved  froa  the 
state  RUNNING  or  VOLUNTARY  SUSPEND.  The  tasks  virtual  processor 
becomes  non-existent  and  the  task  becoaes  unknown  to  the  real 
processor.  The  fora  of  the  call  is: 

CALL  ABORT  (i  , a) 

where: 

i specifies  the  program  to  be  aborted. 

The  argument  is  either: 

a)  an  integer  expression,  or 

b)  an  integer  array  naae,  or 

c)  a procedure  naae 

The  processor  shall  define  which  of  the  above  three 
forms  is  acceptable 

a is  set  on  return  to  the  calling  prograa  to  indicate  the 
disposition  of  the  request  as  follows: 

The  value  must  be  1 or  greater 

1 - request  accepted 

2 or  greater  - request  rejected 

This  argument  shall  be  an  integer  variable  or  integer 
array  eleaent. 
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APPENDIX  A 

This  appendix  is  not  part  of  the  ISA  Standard  S61.2  but  is  included  to 
facilitate  its  use. 

Considerations  leading  to  Inudstrial  Computer  System  FORTRAN 
Procedures  for  File  Access. 

A . 1 Historical  Development 

This  standard  is  a direct  outgrowth  of  the  International  Purdue 
Workshop  on  Industrial  computer  Systems  whose  goals  are: 

To  make  the  definition,  justification,  hardware  and  software  design, 
procurement,  programming,  installation,  commissioning,  operation,  and 
maintenance  of  industrial  computer  system  more  efficient  and 
economical  through  the  development  of  standards  and/or  guidelines  on 
an  international  basis. 

The  Workshop  formed  several  committees  to  achieve  its  objectives.  The 
FORTRAN  Language  Committee  was  charged  with  the  task  of  preparing  a 
set  of  Industrial  Process  standards  compatible  with  standard  FORTRAN. 

This  standard  is  the  result  of  that  committee's  work. 

A. 2 Criteria  Used  in  Developing  FORTRAN  Standards 

The  committee  assessed  the  status  of  FORTRAN  as  used  in  the  industrial 
environment  and  followed  the  guidelines  below  in  the  devlopment  of  the 
standards : 

(1)  The  standards  whould  cover  features  commonly  used  by  existing 
industrial  computer  systems. 

(2)  The  standards  should  be  easily  implemented  by  most  vendors. 

(3)  The  standards  should  follow  the  syntax  and  intent  of  FORTRAN  as 
defined  by  ISO  R1539-1972. 

(4)  The  standards  should  not  restrict  the  future  evolution  of  FORTRAN 
language . 

The  development  of  FORTRAN  language  standards  is  presently  the 
responsibility  of  ANSI/T1J3.  In  order  that  LSA  standards  comply  with 
the  ANSI  standards  as  far  as  possible,  external-procedure  references 
were  used  rather  than  direct  changes  or  additions  to  the  syntax  of 
FORTRAN.  This  does  not  imply  that  this  is  the  only  way  to  provide 
these  features,  nor  does  it  exclude  the  possibility  or  desirability 
that  ANSI  will  develop  the  language  syntax  to  perform  these  and  other 
related  forms. 
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APPENDIX  D 


This  Appendix  is  not  part  of  the  ISA  Standard  S61.3  but  is  included  to 
facilitate  its  use. 


NOTES  BY  SECTION 


B . 1 Section  3 Notes 


The  eventmark  defined  in  this  section  provides  capability  for  handling 
events.  The  use  of  events  is  the  responsibility  of  the  systen 
desiqner  but  two  (2)  common  usuages  can  be  envisaged. 

An  event  can  be  considered  to  be  an  interrupt,  either  hardware  or 
software,  which  exist  in  most  industrial  computer  systems.  The 
occurrence  of  an  interrupt  can  cause  the  executive  routine  to  set  an 
eventmark  and  the  procedure  references  defined  in  Sections  3 and  4 of 
this  standard  provide  all  the  necessary  features  to  control  coaputer 
usage  based  on  interrupts. 

An  event  can  also  considered  to  be  a Dijkstra  P-V  semaphore  and  can  be 
used  for  the  control  of  critical  resources  and  the  resolution  of 
contention  for  such  resources.  The  well-known  one- writer-aany- readers 
problem  can  be  solved  by  using  the  eventaarks  as  seaaphores. 

In  the  use  of  eventaarks  it  is  the  system  designers  responsibility  to 
ensure  that  no  lock-out  conditions  occur.  There  is  no  provision  in 
the  standard  to  ensure  that  inadvisable  use  of  the  eventaarks  will  not 
cause  undesirable  consequences. 

There  is  no  provision  in  the  standard  for  BOOLEAN  operations  on 
eventaarks.  Such  features  aay  be  provided  by  the  executive  program  or 
be  available  at  system  generation  time  and  would  be  processor 
dependent.  The  lack  of  such  features  is  not  intended  to  discourage 
their  inclusion  by  system  suppliers  but  it  is  considered  premature  to 
standardize  on  such  features  at.  this  time. 

B.2  section  4 Notes 


This  standard  is  a permissive  standard  in  that  it  does  not  prescribe 
how  the  executive  will  respond  to  external  procedure  references  nor 
does  it  describe  how  the  information  is  passed  to  the  executive 
routine.  In  particular,  the  argument  "i"  in  CALL  SKED  (4.2),  CALL 
DSKED  (4.3)  and  CALL  ABORT  (4.4)  has  three  forms,  an  integer 
expression,  an  integer  array  name  or  a program  name,  only  one  of  which 
is  permissible  in  any  particular  program.  This  restriction  is  a 
necessary  consequence  of  the  requirements  of  the  FORTRAN  language  that 


-693- 


dp  S6  1 . 3 
JAN  1978 


any  argument  which  is  an  external  procedure  reference  be  of  a defined 
type;  integer  expressions,  integer  array  naaes  and  prograa  naaes  are 
different  types  (Section  8.4.2  of  ISO-R 1539- 1977) . It  is  also  a 
consequence  of  the  FORTRAN  language  that  if  the  arguaent  is  a prograa 
naae,  this  naae  aust  appear  in  an  EXTERNAL  stateaent  (Section  7.2.15 
of  ISO-R1539-1972)  . 

Exaaples  of  the  use  of  the  arguaent  i as  an  integer  expression  are: 


— CALL  ABORT  (7,H) 

--DATA  J/7/ 

CALL  ABORT  (J,H) 

— DATA  J/2HAB/ 
CALL  ABORT  (J,N) 


An  exaaple  of  the  use  of  the  arguaent  i as  an  integer  array  naae  is: 

INTEGER  XTZ 
DIMENSION  X YZ  ( 3) 

DATA  XTZ ( 1 ) , X YZ  (2)  ,XYZ (3) /2HAB, 2HCD, 2HEF/ 

CALL  ABORT  (XYZ,M) 

An  exaaple  of  the  use  of  the  arguaent  i as  a procedure  naae  is: 

EXTERNAL  ABCD 
CALL  ABORT  (ABCD, N) 

Interchangeability  of  prograas  between  different  processors  is  reduced 
by  peraitting  three  possible  types  for  this  arguaent  but  the  coaaittee 
feels  it  is  preaature  to  standardize  to  achieve  full 
interchangeability  in  this  area. 


E . 3 Coaplexity  of  Section  4 calls 

The  calls  for  SEED  and  DSEED  are  very  coaplex  but  are  provided  to 
enable  the  user  to  specify  in  one  atoaic  function  everything  required 
for  either  a scheduling  or  descheduling  action.  Obviously,  not  every 
call  needs  to  be  this  coaplex.  Therefore,  the  siaplier  foras  CYCLE, 
CON,  DCYCLE,  DCON  and  CANCEL  are  included  as  subsets  of  SEED  and 
ESEED.  These  are  proper  subsets  with  the  standard  providing 
inforaation  upon  the  "default"  properties  of  the  unspecified 
arguaents. 
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It  should  also  be  noted  that  several  of  the  procedures  of  ISA 
1976  and  the  FORTRAN  statement  STOP  are  also  subsets  of  SKED, 
and  DELAY.  The  correspondence  is  shown  in  the  following  table: 


CALL  START 
i 

j 

k 

■ 


CALL  TRNON 
i 
1 


S&L3 
CALL  SKED 
i 

t* 

s=5 

■ 

P 

e1 

n 

t* 

c 

t3 

e* 

e3 

CALL  SKED 
i 

t» 


s= 2 
P 

e» 

n 

t* 

c 

t3 

e* 

e3 


CALL  WAIT 

j 

k 


CALL  DELAY 
t* 
s=  1 

■ 

e 


STOP  CALL  ABORT 

i=  naae  of 
current 
prograa 
m 


3 
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Kazimierz  Maliszewski 


September  22,  1977 


MERA-PIAP , WARSZAWA 

NEW  SUBROUTINES  PROPOSED  FOR  RT-FORTRAN 

The  present  working  paper  written  for  the  RT-FORTRAN 
Committee  of  Purdue  Europe  contains  description  of  several 
new  RT-FORTRAN  references. 


1.  New  definition  of  ATIME. 

In  current  form  the  subroutine  ATIME  gives  time  of  day  as 
integer  value  expressed  in  seconds.  As  24  hours  = 86400  sec., 
the  maximal  value  would  exceed  capacity  of  16  bit  word,  fre- 
quently used  in  industrial  installations.  Besides,  1 second 
unit  seems  too  large  for  precise  measurements. 

I propose  two  alternative  versions  of  ATIME. 

t 

Version  1. 


Obtain  time  of  day  expressed  in  desired  units . 
The  form  of  the  call  is: 


CALL  ATIME (a,  k) 
where : 

a designates  a variable  or  array  element  to  receive  the 

time  of  day.  The  result  shall  be  given  in  floating-point 
form,  including  fractional  part.  The  type  of  this  argument 
is  either: 

a/  real 

or  b/  double  precision. 
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The  processor  shall  define  which  form  is  acceptable  as 
well  as  the  accuracy  of  result, 
k specifies  the  units  in  which  the  time  should  be  placed 
in  "a"  as  follows: 

0 - basic  counts  of  the  system's  real  time  clock 

1 - milliseconds 

2 - seconds 

3 - minutes 

This  argument  shall  be  an  integer  expression. 

Version  2. 

Obtain  the  time  of  day  in  seconds . 

The  form  of  the  call  is: 

CALL  AT  IMF,  (a) 

where  a is  defined  as  in  Version  1 with  the  following  addition 
The  time  since  the  beginning  of  day  shall  be  expressed 
in  seconds  with  maximum  accuracy  available  in  the 
system . 

Comments : 

1/  A real  value  is  more  suitable  for  computations  than  an 
integer  one. 

2/  If  real  value  is  stored  on  48  bits,  the  result  has  11-digit 
accuracy.  This  is  enough  to  express  on  day  in  milliseconds 
/ 86 , 400 , 000/ . In  systems  with  smaller  accuracy  the  double 
precision  can  be  used. 

3/  Real  Time  FORTRAN. 

4/  I prefer  the  Version  2. 


2.  Connection  of  an  event  to  a semaphore . 

I submit  for  discussion  a subroutine  called  SKCON . It 
connects  a specified  event  to  a specified  semaphore.  This 
connection  lasts  till  the  event  occurs  or  the  calling  activity 
ends  its  execution.  The  executive  system  will  not  accept  a 
demand  of  connection  if  the  specified  event  is  already  connected 
to  a semaphore.  The  occurrence  of  the  event  causes  an  action 
equivalent  to  that  of  the  SIGNAL.  An  activity  can  await  the 
event  by  calling  the  WAITS.  Thus  the  subroutine  AWAIT  would 
not  be  necessary. 

The  event  can  be  accompanied  by  a transmission  of  data, 
so  the  implementor  may  restrict  using  the  SECON  to  core-resident 
programs . 

The  form  of  the  call  is: 

CALL  SECON  (r , j , k , m) 
where : 

r is  an  integer  expression  specifying  the  semaphore, 
j specifies  the  event  to  be  connected.  This  argument  shall 
be  an  integer  array  name  or  an  integer  array  element, 
k specifies  a space  in  the  calling  program  for  input/output 
data  if  the  event  signifies  end  of  transmission.  The 
use  /or  not/  of  this  argument  depends  on  the  nature  of 
the  event.  The  argument  shall  be  either: 

a/  an  integer  variable  or  an  integer  array  element 
or  b/  an  integer  array  name 

or  c / an  integer  expression  /conditionally  that  data 

are  not  input/ 
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is  an  integer  variable  or  an  integer  array  element  which 
is  set  by  the  executive  system  to  indicate  the  status  of 
the  call: 

m .<  0 - not  defined. 

m = 1 - the  specified  event  has  occurred,  the  transmission 
to/ from  "k"  /if  any/  has  been  finished  and  the 
semaphore  has  been  increased  by  1.  If  new  value 
of  the  semaphore  equals  1,  an  opportunity  is 
given  to  an  activity  waiting  on  the  semaphore  to 
finish  its  suspension. 

m = 2 - request  accepted,  the  specified  event  has  not  yet 
occurred . 

m > 3 - error  conditions.  The  implementor  may  specify  a 
number  of  error  indicating  values  and  state  for 
every  of  them  if  it  is  accompanied  by  an  incrementa- 
tion of  the  semaphore,  or  not. 


Comment 


A separate  call  for  event  description  makes  it  possible 
to  wait  for  a logical  sum  of  several  events.  If  so,  the  wait- 
ing activity  should  search  what  has  happened  after  every  return 
to  state  RUNNING . That  is  achieved  by  testing  status  variables 
"m"  used  in  calls  for  SECON. 

The  note  concerning  two  kinds  of  error  /m  > 3/  means  that 
errors  in  data  transmission  should  increase  the  semaphore,  .so 
that  the  activity  may  not  wait  endlessly.  However  if  the 
system  decides  to  reject  the  call  immediately  after  detec- 
tion, the  semaphore  will  not  be  touched. 
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Actually  SECON  can  be  used  for  initiation  of  a transmission. 
A simplified  flow  diagram  for  a section  of  an  activity  await- 
ing one  of  three  inputs  is  presented  below. 

3.  Error  handling  in  RT- FORTRAN. 


In  the  current  form  of  RT-FORTRAN  a programmer  must  check 
error  parameter  /m/  after  each  call  to  be  sure  that  all  is 
right.  I propose  a subroutine  to  make  this  work  not  necessary. 
The  subroutine  is  called  COSER  /Common  Service  of  Errors/. 

The  form  of  the  call  is: 


i.  i.  J)  | 
pecting  m.  I 


TcALL  COSER  (m, 

! Statement  inspecting 

Arguments : 

m is  an  integer  variable  or  integer  array  element.  RT- 
FORTRAN  references  which  will  subsequently  use  m as 
status  parameter  shall  be  handled  in  case  of  error  in  a 
way  described  further. 

i is  an  integer  expression  having  a value  :>  2.  Error 

handling  shall  take  place  when  m assumes  a value  greater 
than  or  equal  to  "i"  on  return  from  a subroutine. 

j is  an  integer  array  or  integer  array  element  name.  The 
error  handling  system  shall  place  there  all  information 
necessary  to  identify  the  error. 

Pr inciple  of  work: 

1/  Before  the  subroutine  COSER  is  invoked  in  an  activity,  the 
present  error  handling  is  not  undertaken  for  the  activity. 

2/  When  the  COSER  is  called,  it  remembers  addresses  of  "m" 


I 


and  "j"  as  well  as  the  value  of  "i".  The  address  of  the 
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next  statement  after  CALL  COSER  is  also  stored. 

An  error  in  COSER' s parameters  shall  be  signalled  in 
a system- dependent  way. 

3/  After  acceptance  of  actual  arguments  a return  from  COSER 
is  made  with  m=l. 

4/  The  value  of  m should  be  checked  in  calling  activity. 
Logically  this  check  should  be  done  immediately  after 
CALL  COSER.  Nevertheless  no  constraint  exists  whether, 
where  and  how  to  do  a check. 

The  check  should  detect  values  m >,  i signalling  error 
conditions.  This  can  be  done  with  a statement: 

IF  (m.GE.i)  GO  TO  e 

where  "e"  is  a label  in  the  calling  program. 

Of  course,  initially  m=l,  i > 2,  so  the  jump  is  skipped 
and  the  activity  proceeds  farther  to  do  its  normal  job. 

5/  Only  RT-FORTRAN  subroutines  using  as  status  parameter  a 

variable  previously  specified  as  "m"  in  CALL  COSER  are  con- 
cerned. When  return  is  made  from  such  a subroutine  with 
m > i , the  next  executed  statement  is  one  which  follows 
CALL  COSER  with  this  "m"  /and  not  the  statement  following 
subroutine  reference/,  m has  then  an  appropriate  error 
indicating  value,  greater  than  or  equal  to  2.  Correspond- 
ing array  "j"  contains  more  information  about  the  error. 

This  information  shall  have  a system-dependent  form.  At 
least  an  identifier  of  the  subroutine  which  failed  is 
necessary,  I suppose. 
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b/  After  a check  described  in  item  4 the  activity  proceeds  to 
its  own  error  handling  /to  label  "e"  in  the  example  above/. 
7/  Particular  processors  may  declare  how  much  error  variables 
"m"  can  be  declared  by  CALI.  COSER  in  an  activity.  Never- 
theless it  should  be  possible  to  specify  a number  of  pairs: 
m,  i.  This  is  essent  ial  as  not  always  i~2 . Each  CALI. 

COSEK  should  be  followed  by  a check  of  its  "m" . 

On  the  other  hand  repeated  calling  COSKR  with  the  same 
"m"  shall  introduce  new  values  resulting  from  i,  j and 
program  loea t i on . 

Ex  a nip  1 e 

Here  is  a fragment  of  a program  using  the  COSKR  to  detect  an 
error  in  references  to  START,  WAIT  /m  > ?/  and  C.ANCL,  KILL 
/m  * 3/. 


C DECLARE  ARRAYS  FOR  COSKR  AND  KILL 
DIMENSION  K(5) 

C DECLARE  VARIABLE  M FOR  ERROR  VALUES  .CK.  2 
CALL  COSER  (M,2,J) 

IF  (M.GE.2)  CO  TO  1 

C DECLARE  VARIABLE  IN  FOR  ERROR  VALUES  .GE.  3 
CALL  COSER  (N,3,J) 

IF  (N.GE.3)  CO  TO  2 
/program  body/ 


-705- 


If  the  GOBACK  is  called  without  previous  error  service 
originated  by  the  COSER,  the  result  is  not  defined  /unless 
defined  by  the  processor/ . 


? 
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DIGITAL  CONTROL  TECHNOLOGY  R&D 

TENTATIVE  FUNCTIONAL  REQUIREMENTS  AND  DESIGN  GUIDELINES 
FOR  OPERATOR  INTERFACES 


INTRODUCTION 


The  document  describes  the  basic  characteristics  of  current 
operator  interfaces  used  in  Exxon  plants  and  defines  the  functional 
requirements  and  design  criteria  for  future,  centralized,  multiscreen  con- 
soles, Intended  to  be  used  as  the  sole  operator  interface  with  distributed 
and/or  hierarchical  control  systems  for  process  control  of  Exxon's  refineries 
and  chemical  plants. 

The  purpose  of  this  document  is  multifold  and  covers  the  fol- 
lowing areas: 

• Explain  and  document  the  shortcomings  of  current  systems 

• Make  Instrumentation  and  computer  vendors  aware  of  our  requirements 
for  future  operator  interfaces. 

• Establish  a constructive  dialogue  with  interested  vendors  actively 
Involved  in  developmental  effort  in  the  area  of  PMIF. 

• Establish  the  feasibility  and  cost  impact  for  implementing  designs  to 
satisfy  these  requirements  and  develop  the  basis  for  a stepwise 
approach. 


GENERAL 

• Current  operator  Interfaces  consist  of  computer  consoles  and  convention- 
al control  panels  ("back-up"  panel). 

• Computer  consoles  are  driven  by  the  process  control  computers  and  can 
access  and  display  all  process  inputs  connected  to  the  computer  as  well 
as  computer  generated  variables. 

• Conventional  panels  can  only  display  process  Input  & jnals  connected 
directly  to  the  "back-up"  instrumentation  and  data  acquisition  systems. 

Usually  not  all  the  process  variables  displayed  at  or  controlled  from 
the  panel  are  accessible  from  the  computer  console.  This  is  normally 
dictated  by  lack  of  incentives  to  associated  certain  functions  with 
computer  control  and/or  to  duplicate  all  control  functions  of  the 
panel  at  the  computer  console. 

Control  or  display  functions  which  are  usually  not  available  at  the 
computer  console  include  the  following: 

- Dedicated  sequence  controllers 

- On-off  controls  (pumps,  MOV's,  mixers,  etc.)  for  onsites 

- Emergency  manual  shutdown  of  major  process  equipment 

- Certain  process  alarms  (normally  associated  with  the  status  of 
utilities) 

• The  panel  mounted  instrumentation  (displays  and  control  stations)  is 
not  only  used  during  computer  outages  but  also  when  computer  control  is 
available.  In  the  latter  case,  the  panel  Instrumentation  is  mainly  used 
for: 

- Handling  process  upsets 

- Plant  or  unit(s)  start-up  (e.g.,  after  turnarounds) 

- Emergency  shutdown 

A summary  of  the  main  reasons  for  the  use  of  the  "back-up"  panel,  when  the 
computer  (and  computer  console)  are  available,  is  given  below: 


• Handling  Process  Upsets 

- Procedures  to  call  display(s),  select  loop(s)  and  take  corrective 
action  is  slow  and  inadequate  to  handle  most  emergencies. 


i 

I 

i 

I 
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No  computer  console  has  sufficient  overview  capability  to  allow 
surveillance  during  corrective  action. 
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• Plant  Or  Unit(s)  Startup 

- Console  operator  alone  cannot  handle  workload  from  console  during 
start-up  (senior  field  operators  are  also  assisting  using  the 
panel) . 

- Console  overview  capability  very  limited. 

• Emergency  Shutdown 

- Combination  of  the  above. 

BASIC  CHARACTERISTICS  OF  CURRENT  MMIF 
Console  Operator 

• Position  In  Organization 

Normally  (but  not  always)  is  a first  line  supervisor,  directing  the 
field  operators  via  two  way  radio. 

• Selection  Criteria 

- Very  good  knowledge  of  process  units  assigned  to  his  console. 

- Good  knowledge  of  process  units  assigned  to  other  consoles. 

- Good  supervisory  qualities  (more  stressed  in  certain  plants  than 
others) . 

• Available  Pool 
Senior  field  operators 

- Senior  field  operators  can  replace  console  operators  during  scheduled 
and/or  unscheduled  absence. 

Number  of  Computer  Consoles/Control  Room 

• Usually  2 or  3 consoles  - Number,  however,  can  be  as  high  as  5. 

• In  highly  centralized  plants,  several  control  rooms  may  exist  in  the 
same  control  house. 

• There  may  be  an  engineer's  console  in  the  same  control  room.  This 
console  includes  all  the  features  of  the  operator  console  and  can  be 
used  by  the  operators  if  required. 

Characteristics  of  Consoles 

• Normally  of  the  CRT  type  - (15"  diag.  black  & white  or  19"  color). 

• Most  consoles  have  two  CRT  screens  but  number  varies  from  1 to  3. 
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• Being  supported  by  the  same  computer,  all  consoles  can  access  the 
entire  data  base. 

• There  is  one  operator  assigned  per  console.  However,  consoles  with 
multiple  screens  and  keyboards  can  be  used  by  more  than  one  operator 
if  required. 

• In  some  cases,  all  pen  recorders  are  mounted  on  a credenza,  installed 
close  to  the  computer  console. 

OPERATOR  RESPONSIBILITIES  AND  WORKLOADS 
Number  of  Control  Loops/Console 

• Varies  considerably  (from  70  to  250) 

• Number  depends  on: 

- Nature  of  process 
Complexity 

- Degree  of  process  integration 

Note  that  since  the  definition  of  "control  loops"  has  become  rather  loose, 
the  above  figures  are  only  indicative  and  should  be  rather  interpreted  as 
number  of  controlled  outputs. 

Number  of  high  level  (4-20  ma)  inputs/console 

• Varies  from  1.6  to  2 times  the  number  of  "control  loops" 

Number  of  low  level  inputs  (usually  TC  Inputs) 

• Can  be  as  high  as  twice  the  number  of  high  level  inputs. 

• DTI  readout  is  usually  installed  both  at  the  console  and  panel. 

Number  of  alarm  windows  (panel  annunciators) 

• Varies  considerably  but  on  the  average  is  approximately  1.7  times  the 
number  of  control  loops.  A ratio,  however,  of  2-rl  is  not  unusual. 

More  than  90%  of  these  alarms  can  be  displayed  at  the  computer  console. 
(CRT  and/or  printer). 

Software  Generate d Alarms 

• Additional  alarms  (computer  generated)  can  only  be  displayed  on  console 
CRT  or  typed  via  printer.  Again  their  number  varies  considerably  but 
in  general  they  represent  the  major  bulk  of  alarms 
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Operator  responsibilities 

• It  should  be  noted  that  although  there  is  one  console  operator 
assigned  per  console,  other  console  operators  or  senior  field  operators 
may  be  asked  to  assist  if  the  situation  demands. 

As  mentioned  before  a console  operator  is  required  to  know  how  to  handle 
process  units  not  normally  "assigned"  to  his  console.  This  is  translated 
into  the  following  requirements,  generally  met  by  existing  consoles. 

- Ability  to  take  under  control  from  his  own  console,  process  units 
assigned  to  other  consoles,  installed  in  the  same  control  room. 

- Ability  to  monitor  status  of  all  alarms  from  his  own  console. 

• Despite  extensive  use  of  control  computers  for  logging  different 
process  data  and  selected  conditions,  operators  still  maintain  hand 
written  logs.  This  is  mainly  done  in  order  to  retain  access  to  a 
certain  set  of  data  when  the  computer  memory  banks  are  wiped  out 

by  a system  malfunction. 

MAIN  DISPLAY  CHARACTERISTICS 


Pen  Recorders 


• The  number  of  variables  simultaneously  recorded  on  pen  recorders 
(both  shared  and  dedicated)  varies  from  12%  to  42%  of  all  high 
level  inputs.  The  average  is  approximately  30%. 

• Operator  feedback  indicates  that  above  % can  be  reduced -to 
20%  (rule  of  thumb). 

• Almost  all  console  operators  use  pen  recorders  only  for  monitoring 
general  trend  of  variable. 

• Changing  pen  assignment  on  shared  recorders  becomes  very  unusual 
after  few  months  of  operation.  Shared  recorders  have  normalized 
scales,  since  each  pen  can  be  assigned  to  several  process  variables. 

Indicators 


Next  to  the  recorders  is  the  most  easily  scanned  display.  They  are  used 
during  unit  surveillence  and  during  verification  of  alarm  conditions  as 
part  of  the  panel  "overview"  capability. 

Control  Stations  (Back-up) 

• Indicating  lights  are  displaying  the  status  of  the  back-up  instru- 
mentation (absence  of  light  indicates  that  loop  is  under  computer 
control) 
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• The  type  of  back-up  station  (C/M/A-l,  C/M/A-2,  C/M/A-T,  C/M/A-S) 
is  usually  indicated  (via  "dynotaped"  labels)  when  several  back-up 
types  a :e  used. 

• Color  coding  is  widely  used  to  identify: 

- Loop  function  (flow  level,  etc.) 

- Process  unit  or  process  area 

• Control  stations  are  mounted  in  high  density  arrays.  Installation 
density  of  10  rows  by  10  columns  per  panel  section  is  widely  used 

in  all  recent  installations,  although  actual  occupancy  rarely  exceeds 
60%.  The  density,  expressed  in  terms  of  loops/linear  ft  of  panel 
varies  fr-m  7 to  11  loops/linear  feet  (includes  spare  space,  recorders 
etc.).  The  higher  densities  are  achieved  with  Foxboro  minaturized 
displays. 

Alarms  Annunciators 


• Dimensions  of  windows  vary  from  full  size  down  to  1 1/2"  x 3/4” 

• Identification  bv  console  operators  sitting  at  console  is  via 
pattern  recognition. 

• Shrill  audible  alarm  signal  irritate  operators  the  most.  In  some 
instances  entire  sections  of  annunciators  are  permanently  silenced 

• Different  priorities  of  alarms  are  indicated  by  means  of  color  coding 
(colored  celophane  placed  behind  alarm  window)  and/or  different 
audible  signals. 

• Extremely  useful  is  the  use  of  different  audible  signals  for  different 
console  areas  (within  the  same  control  room). 

Graphic  presentation  of  process 

• Semi-graphic  panels  are  not  used  anymore 

• Only  OM&S  CRT  consoles  have  extensive  library  of  graphics  (interactive) 

• With  few  exceptions  (mainly  experienced  operators),  onsites  operators 
miss  the  graphic  presentation.  (In  all  plants  visited-except  one- 
P&ID's  were  attached  with  cellotape  on  spare  panel  spaces). 

CRT  consoles 


• The  most  widely  used  display  format  is  the  multiloop  format. 
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• The  following  information  is  normally  displayed  with  multiloop 
formats 

- Tag  I.D.  (or  loop  I.D.) 

- Tag  description 

- Current  value  of  variable  (measured  or  calculated) 

- Set  point  (or  target) 

- Tag  status  (control  mode) 

- Valve  position  (control  output) 


• The  number  of  loops  (or  tags)  displayed  on  multiloop  formats  varies 
fror  10  to  a max.  of  32.  Usually  is  less  than  16. 

• Interactive  graphic  displays  of  process  units  or  areas  ar.e  only 
used  in  OM&S  applications.  For  onsites  applications,  graphic 
capabilities  of  computer  consoles  is  not  used  (effort  to  built 
displays  appears  disproportionate  compared  to  usefulness). 

• CRT  trending  capability  is  hardly  used  because 

- Procedure  to  call-up  (or  built)  display  is  time  consuming 

- Trending  starts  without  previous  history 


It  is  much  easier  to  scan  the  pen  recorders 

• Bar  graph  presentation  of  process  variables  is  very  useful  when 
variables  are  logically  associated  and  form  distinguished  patterns 
(e.g.  temperature  profiles,  flow  balancing  in  multipass  furnaces, 
etc . ) 

The  majority  of  operators  would  prefer  this  type  of  presentation 
also  for  multiloop  formats. 

Console  alarming  features 

• Worst  presentation  of  alarm  messages  is  via  printer 

• CRT  alarming  is  prefrred  by  operators  over  printed  messages 


• Only  highest  priority  alarms  are  automatically  displayed  on  CRT 
screen  (no  operator  search).  Usually,  separate  screens  or  dedicated 
portion  of  screen  is  used  for  alarm  messages. 

• Usually  pattern  recognition  is  not  maintained  with  CRT  alarm  displays 
(i.e.,  alarm  messages  do  not  appear  on  predetermined  screen  areas  but 
as  they  occur  in  a push-up  or  push-down  stack  configuration.) 

Pattern  recognition,  however,  is  sometimes  maintained  on  alarm  key- 
boards (normally  separate  from  main  operating  keyboard). 
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Other  CRT  con  so  ] e d fsj>l  ay  forma  t s 

A variety  of  other  CRT  display  formats  are  being  used  such  as 

- Loop  interconnection  diagrams  (block  diagrams  of  multicascades) 

- Logging  of  significant  changes  initiated  by  operators 
(inhibited  alarms,  changes  of  alarm  settings  etc,). 

- Logs  of  process  variables  (measured  or  calculated). 

- Plots 

- Daily  schedule  of  tasks  (usually  for  OM&S  operation) 

Reports 

A variety  of  reports  can  be  Obtained  via  printer  (Historical  data, 
hourly  averages,  daily  averages,  daily  reports,  monthly  averages,  etc.). 

HUMAN  OPE RAT 1 NC  MODE S 


In  general,  the  operator  functions  in  the  following  basic 

inodes: 

a)  Process  Surveillance 

During  this  mode,  operators  monitor  the  overall  status  of  the  process 
units  assigned  to  them  using  operation  by  exception  techniques.  They 
normally  function  in  this  mode  when  the  units  are  lined-up  and  on 
target . 

Operators  normally  monitor: 

- trend  of  key  variables  (glancing  at  pen  recorders) 

- 6tatus  of  variables  associated  with  acknowledged  alarms 
(there  are  always  several  alarms  in  acknowledged  condition) 

- status  of  controlled  variables  that  control  is  placed  on  manual. 

The  exceptions  could  be: 

- New  alarm  conditions  (but  low  priority  alarms  are  normally  ignored) 

- Wide  deviations  of  process  variables  from  set  points 

- Computer  generated  messages 

- Sudden  change  of  trends 
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During  this  mode  of  operation,  they  glance  at  the  panel  because: 

- of  Its  overview  capability  (no  need  for  search,  such  as  paging 
through  CRT  displays) 

- it  is  there  (habit) 

Most  operators  prefer  to  anticipate  disturbances  that  can  result 
in  tripping  critical  alarms.  They  don’t  want,  however,  to  be 
continuously  reminded  of  the  same  abnormal  condition  (as  it 
happens  when  the  same  alarm  message  keeps  repeating  itself  even 
when  it  has  been  acknowledged). 

b)  Unit  Monitoring 

During  this  mode,  they  take  a "closer  look"  at  individual  process 
units.  They  normally  enter  this  mode  as  a result  of  a noticed 
exception,  at  the  recovery  stage  of  an  upset  or  when  they  do  expect 
some  problems  as  a result  of  changing  conditions  in  other  process 
units. 

During  this  mode  they  usually  employ  "pattern  recognition"  techniques 
such  as: 

- Bar  graph  presentation  of  related  variables  (when  available  on  CRT) 

- Trend  of  key  variables  of  that  unit  and  relative  position  of  trends 

In  addition  they  pay  closer  attention  to  digital  values  of  key 
variables  (usually  one  or  two  multiloop  displays). 

Computer  consoles  appear  adequate  for  this  type  of  operation  (except 
for  trend  monitoring)  but  improvements  can  be  made  in  the  following 
areas: 

- Data  presentation  for  multiloop  displays  (searching  for  off  normal 
patterns  in  terms  of  deviation  from  targets  or  set  points  is 
difficult  when  data  is  presented  only  digitally). 

- Passing  from  one  display  to  another.  Preferred  method  is  by 
dedicated  keys  (single  action).  Other  methods  that  definitely 
assist  operators  are: 

+ Ability  to  easily  address  displays  associated  with  the  one 
under  current  observation  and  return  to  previous  display. 

(These  displays  may  not  be  always  in  numerical  sequence  and 
"paging"  is  not  sufficient.) 

+ Ability  to  page  through  multiloop  displays  (forwards  and  back- 
wards) is  useful  when  the  tags  - logically  associated  with  a major 
piece  of  equipment  or  parallel  trains-oxcccd  the  display  capacity 
of  a single  multiloop  format 


During  this  mode,  operators  do  glance  at  the  panel  (normally  the 
set t ion  grouping  t ho  panel  Instruments  of  the  unit  being  monitored). 
However,  if  this  section  is  not  easily  visible  from  the  consol c-or 
not  visible  at  all-very  few  operators  walk  to  the  panel. 

c)  Interactive  Mode 

In  this  mode  the  operator  Interacts  with  the  process  which  is  changing 
status  lit  a rather  pi  eder lermined  way.  Operator  enter  in  this  mode 
usually  under: 

- Planned  startups  or  shutdowns 

- Beginning  or  end  ot  a process  cycle 

- Planned  changes  in  process  conditions  (e.g.,  i eod  changes, 
target  changes,  etc.). 

Minor  disturbances  associated  with  a major  equipment  group  in 
tire  process  unit  (such  as  a tower,  reactor,  furnace,  etc.) 

Puring  this  mode  of  operation,  set  point  and  valve  position  adjust- 
ments as  well  as  loop  mode  change:,  are  commonly  made. 

Except  for  startups  or  shutdowns,  operators  remain  usually  at  the 
console  (provided  that  console  allows  valve  position  adjustments  in 
manual  mode).  Computer  control  strategics  greatly  assist  operators  in 
most  of  the  above  listed  cases,  reducing  the  amount  of  human  inter- 
vent ion. 

As  far  as  major  startups  ai e concerned,  no  one  polled  has  ever  attempted 
one  from  a computer  console.  Start-up  is  usually  carried -out  I torn  the 
back-up  inst rument at  ton  (mostly  on  manual).  Control  is  switched 
to  computer  when  the  process  Is  basically  within  operating  limits. 

In  order  to  handle  startups  from  a CKT  type  console,  the  desireahle 
enhancements  briefly  mentioned  tot  other  operating  modes,  become  now 
a must.  In  summary  t hoy  arc: 

- Increased  overview  capability  (at  least  same  as  that  provided 
by  the  conventional  panel) 

- Multiple  keyboards  and  screens  to  he  used  hy  more  than  one 
operator. 

- Improved  display  accessibility  in  multilevel  hierarchical 
display  cont  Iguvat  ions 

- Easy  association  ot  displays  . 
loop  level). 


it  same  hierarchical  level  (multi- 
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d)  Emergency 

This  can  be  considered  as  a special  case  of  the  "interactive"  mode  In 
which  one  or  several  process  units  have  been  placed  in  an  unexpected 
upset  situation,  usually  brought  about  by  failure  of  a major  piece  of 
process  equipment,  by  activation  of  a safety  shutdown  system  or  by 
partial  failure  of  the  control  instrumentation. 

Recovery  from  a major  upset  condition  is  the  most  critical  mode  of 
operation.  The  steps  to  recover  from  such  an  upset  cannot  be  anticipat- 
ed In  advance  except  in  those  cases  were  the  cause  of  the  upset  is  a 
predefined  possible  event  (such  as  the  activation  of  a safety  shut- 
down system  tripping  a major  piece  of  equipment)  and  the  effects  can 
be  predicted  to  a large  extent.  Other  upsets,  caused  for  example  by  a 
tube  rupture  In  a furnace  or  loss  of  control  signals  to  several  valves 
must  be  handled  as  the  situation  demands. 

During  this  operating  mode,  several  loops  are  usually  placed  in  a 
manual  status  and  the  operator's  principal  attention  is  focused 
on  the  current  and  near  future  course  of  plant  operation  with  the  aim 
of : 


- protect  the  equipment  from  being  damaged 

- recover  from  the  upset  situation 

- prevent  the  effects  of  the  current  upset  to  propagate  to  other 
process  units  or  group  of  equipment. 

As  mentioned  before,  computer  consoles  are  generally  inadequate  to 
handle  most  process  upsets.  No  operator  has  ever  attempted  to  handle 
a major  upset  from  the  console. 

An  analysis  of  "predicted"  upsets  in  9 different  plants  indicated  that: 

- the  number  of  loops  to  be  manipulated  in  fast  sequence  (worst 
cases)  varies  from  2 to  15.  In  most  cases  is  around  4-6. 

- the  time  available  for  corrective  action  before  the  upset 
propagates  to  other  units,  varies  from  10-15  sec.  to  10-20  min. 

- the  minimum  number  of  trends  to  be  displayed  simultaneously 
("selective"  overview)  to  assess  the  impact  of  corrective  action 
and/or  status  of  key  variables  of  oilier  process  units  appears  to 
be  20. 


bo  made  feasible  but  can  als  offer  certain  improvements  over  the  cur- 
rent use  of  existing  "combination"  interfaces  (computer  console  and 
back-up  panel). 

The  basic  requirements  appear  to  be: 

- The  procedures  to  call  required  displays  should  be  as  fast  and 
simple  as  possible  (single  action). 

Accessibility  to  the  loop  level  (loop  selection  and  modification 
oi  its  status  or  manipulation  of  the  accessible  parameters)  should 
be  at  least  equivalent  to  the  degree  of  accessibility  that  operators 
have  from  convent  tonal  panels. 

- "Associated"  displays  (trends,  multiloop,  etc.)  should  be  called-up 
quickly  for  selective  overview  at  the  same  or  different  hierarchical 
display  level  from  which  corrective  action  is  being  taken.  Selective 
overview  should  not  substitute  higher  levels  of  overview  which  are 
intended  to  provide  the  operator  with  a "bird's  eye"  view  of 
process  operation. 

The  consideration  of  "special"  features,  such  as  specially  built  multi- 
loop displays  with  common  or  preset  action  may  also  assist  the  operator 
in  tinndling  "predictable"  upsets. 

The  use  of  special  software  programs  to  diagnose  abnormal  process  con- 
ditions may  also  assist  in  handling  certain  categories  of  upsets. 

The  definition  of  such  packages,  however,  is  outside  the  scope  of  this 
document . 

Tt  should  be  noted  that  in  general,  the  course  of  upsets  is  by  large 
unpredictable  and  reliance  on  automation  or  predetermined  action  is  by 
no  means  considered  sufficient.  The  basic  design  requirements  therefore, 
should  remain  focused  on  the  human  operator  so  that  he  can  easily  assess 
the  situation,  and  intervene  at  any  time  and  with  a degree  of  freedom 
at  leisi  equivalent  to  that  ofloiod  by  both  levels  of  current  inter- 
faces (panel  and  console). 
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DEFINITIONS 
Plant  : 

Onsitcs  : 

Utilities: 

OM&S  : 


Control  : 
House 
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A group  of  process  units,  integrated  together  with  various  de- 
grees of  interaction.  A plant  includes  the  manufacturing  faci- 
lities for  intermediate  or  finished  products,  utilities  for  its 
operation  and  facilities  for  receiving  and  delivering  feed  stock 
or  finished  products. 

The  part  of  the  plant  that  is  manufacturing  basic  nnblended 
components  or  finished  products  from  natural  feedstock  (crude 
oil,  coal,  brine,  etc.)  or  preprocessed  chemical  feeds  (naphtha 
etc.)  Blending  of  produced  components  may  or  may  not  be  Included. 

The  part  of  the  plant  that  generates  and  distributes  basic  utili- 
ties required  for  the  process  equipment.  It  includes  steam,  com- 
pressed air  (instrument  and  plant),  water  (cooling,  fresh)  elec- 
tricity (high,  medium  and  low  voltages,  including  instrument  power 
Supply  systems)  as  well  as  other  utilities  such  as  inert  gas. 

Oil  movements  and  storage  Is  the  part  of  the  plant  that  usually 
contains  the  equipment  for  storing  finished  products  or  basic 
components  for  blending.  Blending  may  or  may  not  be  part  of  OM&S . 

It  also  includes  facilities  for  receiving  or  shipping  products 
(such  as  truck  loading,  car  loading,  ship  loading  etc.)  Most 
shipments  are  under  "custody  transfer." 

A building,  normally  of  blastproof  construction,  where  centralized 
control  of  several  units  is  carried-out.  The  control  house  in- 
cludes appropriate  space  for  the  installation  of  process  control 
computers  and  their  peripherals,  utilities  (equipment  power  supply, 
air  conditioning  and  filtering),  termination  for  field  wiring, 
Instrument  racks,  etc.  It  also  includes  the  control  room  from 
where  process  operators  monitor  the  process  and  intervene  as  re- 
quired. The  number  of  control  houses  in  a plant  may  vary  from 
one  (full  consolidation)  to  several  (partial  consolidation). 
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PART  II 

FUNCTIONAL  REQU IRK ME NTS  KOR  FUTURE  OPERATOR  INTERFACES 


INTRODUCTION 


The  following  requirements  are  addressing  desirable  features  and 
improvements  over  existing  designs  in  order  to: 

- Overcome  identified  shortcomings 

- Achieve  more  effective  data  presentation 

- Allow  total  operation  from  a single  working  station  under  all  operating 
inodes  (surveil lance,  monitoring,  interactive,  emergency) 

The  requirements  listed  in  this  specification  have  been  defined 
without  considering  the  limitations  of  current  technology  or  the  economic 
impact  for  their  implementation.  As  such,  they  represent  a set  of  basic 
features  for  future  console  designs  and  should  be  considered  as  a starting 
point  for  further  elaboration  aiming  at: 

Establish  the  feasibility,  cost  impact  and  time  frame  for  Implementing 
such  designs  or  alternates 

Establish  the  basis  for  a stepwise  approach 

Initiate  a constructive  dialogue  with  c.omput er / instrumentat ion  system  vendors 

Environmental  Considerations 


The  operator  interface  covered  in  this  specification,  is  intended  to 
be  installed  in  a control  room  type  environment.  This  implies  that 
the  room  is  expected  to  be  air  conditioned,  will  be  generally  free 
from  harmful  gas  concentrations  and  will  have  a ”non-hazardous" 
electrical  classification.  Nevertheless,  the  hardware  should  be  designed 
to  meet  the  following  environmental  requirements: 

Normal  Rand 

Ambient  Temperature  15-35°C 

Relative  Humidity  (2)  10-50 

H^S  Concentration  0.5  ppm 

ControJ  Con f igurat ions 

Control  configurations  applicable  in  this  specification  could  be  one 
of  the  following: 

a ) Computer  bas ed t central! zed 

- Computer(s)  and  instrumentation  Installed  in  the  control  house 

- Supervisory  control  done  entirely  at  the  computer  level 


Operative  Limits 

0-43®C 
10-90 
10  ppm 
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- DDC  may  be: 

4 Done  entirely  at  the  computer  level  (role  of  instrumentation 
is  strictly  for  computer  back-up) 

4 Done  also  at  the  instrumentation  level  (degree  of  integration 
may  vary) 

- The  computer  system  may  be  of  a distributed,  multiprocessor  type. 
Processor  to  processor  and  processor  to  bulk  memory  communication  is  en- 
visaged via  a high  speed  digital  communication  system  (data  rates  are 
expected  to  be  several  Mbyte/sec.) 

- The  computer  system  may  be  interfaced  with  the  instrumentation 
and  other  data  acquisition  systems  (DTI's,  DVl's.tank  gauging, 
etc),  via  a medium  speed,  serial  communication  link.  The 
characteristics  of  this  serial  link  are  expected  to  meet  the 
ISA  SP72  requirements.  Direct  inter  face  to  the  high  speed  bus  via 
1/0  devices  is  not  excluded. 

- The  instrumentation  and  data  acquisition  devices  may  be: 

4 Digital,  pP  based  (from  one  or  several  vendors) 

4 Hybrid 

b)  Computer  based,  dispersed 

Same  as  above,  except  that  control  and  data  acquisition  instrumentation 
may  be  totally  or  partially  installed  in  locations  remote  from  the 
control  house. 

c ) Stand  Alone , Centralized 

Same  as  (a),  except  for  computer  system.  Control  and  data  acquisition 
devices  may  still  be  interfaced  with  a medium  speed,  digital  com- 
munication link. 

d)  Stand  Alone,  Dispersed 

Same  as  (b)  except  for  computer  control. 

It  should  be  noted  that: 

- Prevailing  types  will  be  either  (a)  or  (b) 

- In  all  cases,  operation  will  be  from  a central  location  (control  house) 

- The  data  communication  subsystem  should  be  able  to  support  remotely 
located  consoles.  These  consoles  may  not  have  all  the  interactive 
features  of  the  control  room  console  but  they  will  generally  have 
access  to  the  same  data  base,  addressable  over  the  communleat ion 
subsystem.  Other  limitations  may  be  applicable  (e.g.,  changing 
control  loop  parameters)  but  these  should  be  implemented  via  so(t- 
ware  interlocks. 
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BASIC  DF.SCRI  PTION 
General 


The  purpose  of  the  operator's  console  covered  in  this  specification 
is  to  provide  the  process  operator  with  the  means  of  communication  with  the 
process  units  under  his  control  as  well  as  with  all  the  components  of  the  con- 
trol system  (computers  and/or  instrumentation). 

Since  this  console  is  intended  to  be  the  sole  operator  interface, 
the  reliability  aspects  of  the  design  assume  primary  importance.  The  design, 
therefore,  should  include  the  required  hardware  redundancy  such  that  the 
operator  will  be  able  to  maintain  both  surveillance  and  manipulative  contact 
with  the  process  at  alJL  times.  Depending  on  the  configuration,  degree  of 
sophistication  and  reliability  of  the  distributed  computer  control  system, 
the  operator  console  could  have  one  of  the  following  configurations: 

a)  Stand  alone  system,  independent  from  the  process  control  system  and 
supported  by  its  own  processors,  dedicated  exclusively  to  the  task 

of  retrieving  the  required  information  and  support  the  display  formats 
and  other  features  covered  in  this  specification. 

b)  Directly  supported  by  the  distributed  computer  system  and  acting  as 
"shared"  peripheral.  This  configuration  will  only  be  acceptable  if 
the  overall  reliability  of  the  distributed  computer  system  ensures 

a console  availability  at  least  equal  to  that  of  the  stand  alone  con- 
figuration. 

In  either  case,  the  operator  console: 

• should  be  capable  of  communicating  with  any  device  (passive  or  active) 
attached  to  the  communication  subsystem  that  may  be  used  with  any  of 
the  possible  control  configurations  described  previously. 

• should  include  the  required  degree  of  redundancy  and  modularity  to 
eliminate  any  possibility  (at  least  statistically)  of  total  failure. 

• should  be  free  of  interactive  failure  modes  that  can  affect  either 
the  commun^^tion  subsystem  or  any  control  or  data  acquisition  device 
(computers,  analog  or  digital  instrumentation,  peripheral  equipment 
etc.)  connected  to  the  communication  subsystem. 

• should  be  capable  of  maintaining  all  the  manipulative  and  display 
features  even  in  case  of  partial  failure. 

Since  a console  configuration  of  a stand-alone  type  poses  certain 
specific  design  requirements  th.it  may  be  either  non-existent  or  dealt  with 
by  different  approaches  for  configurations  described  under  "b",  this  specifica- 
tion will  mainly  address  the  stand-alone  type.  Although  different  configura- 
tions arc  net  excluded,  they  should  provido-as  a minimum-the  same  degree  of 
operability,  flexibility  and  overall  reliability  of  the  stand-alone  type 
covered  in  this  specification. 
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Figure  1 shows  sc hemal leal ly  an  overall  system  configuration.  It 
is  envisaged  that  the  control  room  operator  consoles  should  be  connected  to 
the  high  speed  bus  used  by  the  distributed  multiprocessor  control  system, 
while  remotely  installed  consoles  (when  provided)  may  be  either  connected  to 
the  medium  speed  serial  bus  or  connected  to  the  high  speed  bus  via  modems. 

In  any  case,  the  remote  consoles  should  be  able  to  access  data 
available  at  the  high  speed  communication  subsystem.  The  reliability  re- 
quirements for  remotely  installed  consoles  may  vary  depending  on  how  these 
consoles  will  be  used.  As  a minimum,  and  when  these  consoles  are  only 
used  for  read-out  purpose,  no  console  failure  mode  will  ever  affect  the 
communication  subsystem  or  any  control  or  data  acquisition  device  connected 
to  this  subsystem. 

Figure  1 also  shows  additional  terminals  intended  for  the  use  of 
other  groups  such  as  engineering,  control  applications  and  maintenance. 

This  specification  will  not  cover  the  requirements  for  such  devices  except 
from  a very  general  point  of  view. 

It  should  be  pointed  out  that  the  operator  console  should  be 
designed  to  satisfy  primarily  the  needs  of  process  operators  and  not  those 
of  other  working  groups. 

Overall  Design  Requirements 

For  Stand-Alone  Consoles  (Con t ro 1 Room) 

The  operator  console  should  be  made  up  of  at  least  two  completely 
independent  modules  (or  stations)  such  that  failure  of  one  will  not  affect 
the  operation  of  the  other.  Each  module  should  have  its  own  CPU,  memory, 
drivers,  etc.,  required  to  handle  on  an  independent  basis  the  total  load.  A 
console  data  base  should  be  sized  on  the  basis  of  worst  load  conditions 
summarized  in  Table  1.  Table  2 summarizes  the  load  conditions  for  a typical 
OM&S  application. 

As  pointed  out,  the  total  number  of  tags  given  in  Table  1,  are 
approximately  11  tiroes  the  corresponding  number  of  control  "loops".  For 
example,  the  displayed  tags  associated  with  an  extra-large  plant  are  estimat- 
ed on  the  basis  of  1000  loops  (defined  as  control  points  with  "valve"  output 

to  the  process) . 

These  load  conditions,  stated  for  sizing  the  data  base  of  a con- 
sole, should  not  be  confused  with  the  "normal"  load  assigned  to  a console 
operator.  Based  on  current  data,  it  is  not  expected  that  console  operators 
should  ever  be  assigned  more  than  300  "loops".  On  the  other  hand,  the  console 
should  be  able  to  access  all  the  tags  meant  to  be  displayed  or  manipulated 
so  that  any  process  unit  or  group  of  units  can  be  assigned  to,  or  taken  under 
control  from  any  of  the  operator  consoles  installed  in  the  same  control  room. 
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LOAD  ANALYSIS  FOR  OKSITES  OPERATOR  CONSOLES 


Totals  are  approximately  11  times  the  corresponding  number  of  control 
"loops"  (i.e.,  control  points  with  valve  output). 
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The  variety  of  plant  sizes  as  well  as  the  requirement  of  unrestrict- 
ed tag  assignment  will  be  probably  one  of  the  major  factors  in  defining  the 
degree  of  modularity  and  expandability  of  each  module.  This  specification, 
however,  does  not  intend  to  address  the  design  characteristics  of  a module 
but,  rather  the  conditions  defining  the  design  boundaries  for  a variety  of 
alternative  implementations  that  will  be  considered  acceptable. 

Mini  mum  Pat  a B a sc  / Modi  i le 

In  the  case  of  minimum  redundant  configuration  (two  modules), 
sizing  of  the  data  base  for  each  module  should  be  based  on  the  following 
considerat ions: 

• Each  module  should  be  able  to  access  and  process  all  tags  for  display 
and/or  manipulative  purpose  as  well  as  support  the  interactive 
features  described  later  on  under  "Display  Characteristics". 

• It  is  acceptable  that  only  a portion  of  the  data  base  (representing  the 
console  "normal"  load)  may  be  active  all  the  time.  The  inactive 
portion  (representing  the  remaining  load)  may  be  activated  on  demand 
but  will  neither  displace  or  dlactivate  the  "active"  data  base,  nor  slow 
down  the  console's  response  time  by  more  than  25%. 

• Activation  of  the  "inactive"  data  base  should  not  exceed  5 sec.,  and 
should  be  initiated  from  the  console  keyboard  by  single  action. 

If  tiie  console  is  made-up  of  several  modules,  distribution  of  the 
data  base  over  several  modules  will  also  be  acceptable,  provided  that: 

• Availability  of  data  for  display/manipulat ive  purpose  does  not  depend 
exclusively  on  the  availability  of  a particular  module. 

• On-line  reallocation  of  tasks  is  possible  via  program  down- 
loading, or  other  techniques,  affecting  no  more  than  one  module  and 
not  restricted  to  sped  tic  modules  only. 

• Downloading  should  be  as  simple  as  possible,  should  be  Initiated  from 
the  keyboard  and  should  be  completed  within  10  sec. 

• Any  "overloaded"  modules  will  still  be  able  to  perform  its  previous 
tasks  in  addition  to  the  now  ones.  Under  no  circumstances  should  the 
response  time  increase  by  more  than  507.  of  its  normal  value. 

As  mentioned  before,  this  specification  does  not  exclude  alternate 
methods  of  dealing  with  the  basic  requirements  which  can  be  summarized  as 
fol lows: 

• The  design  should  statistically  exclude  total  failure  of  the  operator 
interface. 
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• The  display,  manipulative  and  interractive  features  of  each  console 
should  remain  intact  under  partial  failures  with  a minimum  degree  ol 

degradation. 

• Each  console  operator  should  be  able  to  take  under  his  control  any 
process  unit  assigned  to  other  consoles. 

Data  Base  Spare  Capacity 

A spare  capacity  of  at  least  10X  should  be  provided. 

Ta£  Def in  it  ion 

For  the  purpose  of  this  specification,  a "tag"  is  defined  as 
the  first  level  of  logical  division  of  the  overall  system  data  base. 

A tag  is  not  necessarily  associated  with  a process  unit  control 
loop  and  in  general  may  contain  other  data  such  as  miscellaneous  data 
shared  by  a number  of  control  loops,  additional  inputs  or  information  to 
calculate  certain  process  variables  not  directly  measurable  (e.g.,  net 
tank  volumes)  or  to  define  the  status  of  a control  device  and  its  phase 
in  a sequence  control  application  (e.g.,  motor  operated  valves). 

Although  a tag  is  logically  a single  entity,  it  will  be  normally 
composed  of  functional  sub-entities  that  may  reside  in  dlffetent  places 
throughout  the  distributed  multicomputer  system.  These  sub-entities  are 
associated  with  a variety  of  functions  that  may  be  performed  on  a tag,  such 
as  for  example  filtering  or  other  input  processing,  control,  history, 
association  with  other  software  programs,  output  processing  etc. 

In  general,  process  tags  that  have  no  control  function  associated  with 
them  are  of  the  "intormat ion-only"  type.  If  a control  function  is  associated, 
then  the  tag  will  normally  correspond  to  a feedback  loop  with  an  input  and 
output  associated  with  it.  It  should  he  pointed  out,  however,  that  this  is 
a rather  simplistic  picture,  since  the  details  of  tag  processing  are  quite 
complex. 

For  the  purpose  of  this  specification,  it  should  bo  assumed  that 
tag  processing  is  done  by  other  devices  of  the  distributed  control  system. 

The  processors  supporting  a stand  alone  con; ole  will  normally  retrieve  the 
already  processed  data  associated  with  tin*  tags  and  display  them  in  the  de- 
sired formats. 

Control  and  Data  Presentation  Transparency 

Undoubtedly,  tag  processing  by  other  devices  that  may  not  be 
available  1001  of  the  time  will  have  an  impact  on  the  operator  interface. 

This  may  involve  (as  with  todays  computet  based  control  systems)  a tall  back 
to  a different  and  usually  degraded  type  of  control  stiategy.  From  an 
operator  console's  point  of  view,  it  is  highly  desirable  that  both  data 
presentut ion  and  control  strategy  remain  unchanged.  It  should  be  kept  in 
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mind  that  one  of  the  basic  shortcomings  of  current  operator  interfaces  is 
the  need  to  learn  a variety  of  "back-up"  control  strategies  which  are  much 
less  effective  and  in  most  cases  totally  different  than  the  normal  computer 
control  strategies. 

The  solution  to  the  problem  would  involve  the  overall  architecture 
of  the  control  system  , the  degree  of  its  redundancy  and  the  level  of 
integration  between  the  instrumentation  and  the  distributed  computer  system 
and  is  therefore,  outside  the  scope  of  this  specification.  It  is  important, 
however  to  emphasize  that  if  the  control  system  Includes  one  or  more  levels 
of  "back-up"  control  strategies  the  operator  console  should  meet,  as  a 
minimum,  the  following  requirements: 

• It  must  automatically  recognize  any  condition  that  will  force  the  control 
system  to  a "back-up"  level  of  control  strategy. 

• It  must  revert  automatically  to  display  formats  compatible  with  the 
degree  of  tag  processing  and  level  of  control  strategy  performed  now 
by  the  back-up  control. 

• It  should  clearly  indicate  on  any  affected  level  of  display  (by 
symbolic  coding  or  other  techniques)  the  status  of  tags  that  may 
eventually  require  operator  intervention  in  order  to  he  commissioned 
for  the  type  of  control  they  have  been  assigned  to. 

Figure  2 illustrates  this  concept  with  a very  simple  example  of  possible 
back-up  control  strategy  of  the  type  used  currently. 

Examples  of  Tags 

This  specification  does  not  intend  to  cover  in  detail  neither 
the  tag  structure  nor  the  processing  of  the  tags.  The  following,  are 
representative  examples  of  tags  that  should  be  displayed  on  the  console 
operator.  Accessibility  to  tag  parameters  is  discussed  under  "display 
character ist ics" . 

• controlled  variable  (control  tag)  usually  including 

- input  (eventually  conditioned) 
output 

set  point 

- control  algorithm 

associated  with  each  control  tag,  the  following  parameters  may  he 
included . 
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- alarm  limits  (deviation,  Input  absolute,  input  rate  of  change,  failed 
input, set  point,  output) 

- operating  limits  (input,  output,  set  point,  Integral  mode,  etc.) 

- operating  parameters  (rat  io  roeff ic . , bias,  input  time  constant, 
tuning  constants,  etc.) 

• non  controlled  variables  (information  only) 

input  (eventually  conditioned) 

- target  (if  applicable) 

input  alarm  limits  (same  as  control  tags) 

• calculated  variables  (control  or  information  only). 

• Alarm  inputs,  including 

- input  (two  state) 

- operating  limits  (e.g.,  adjustable  dead  band) 

• Two  state  variables  including: 

- on-off  type  inputs  (usually  two  or  more) 

- on-off  output (s) 

- operating  limits  (e.g.,  adjustable  time  limits  for  expected  completion 
of  command) 

- operating  parameter  (normal /abnormal/ intermediate  status) 

These  tags  are  usually  associated  with  the  status  of  motorized  equipment 
such  ns  MOV's,  pumps,  mixers,  etc. 

For  the  purpose  of  this  specification,  auxiliary  calculations  (such  as 
multiplication,  division,  input  dynamic  compensation,  signal  selection, 
etc.)  ate  not  considered  tags.  These  calculations  are  to  be  considered 
as  associated  with  the  processing  of  tags. 

Usually,  elements  performing  auxiliary  calculation  (whether  defined  as 
"blocks",  "slots",  "tags"  or  subroutines  in  current  software  packages), 
arc  not  required  to  be  displayed  on  the  operator  console,  except  in 
special  "block  diagram"  displays  of  certain  control  configurations,  or 
when  the  information  to  be  displayed  is  only  available  from  such 
elements. 
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Overajl  Display/Manlpulat  ive  Capability 

• Each  module  should  bo  capable  of  supporting  up  to  4 screens,  each  with 
Its  own  independent  keyboard. 

• Each  screen  should  be  capable  of  displaying  all  available  formats  with 
the  possible  exception  of  graphic  presentation  of  process  units  (i.e. 
in  general,  they  shal 1 not  be  dedicated  screens  to  specific  type  of 
display  formats). 

• Special  keyboards  such  as  those  eventually  used  for  data  base  configura- 
tion, building  graphic  displays  etc, that  include  dedicated  functions 
used  very  seldom  by  process  operators,  should  be  detachable  via  plug- 
in connectors  so  that  they  are  used  only  when  required  and  avoid  clut- 
tering of  the  working  area. 

• To  the  maximum  extent  possible,  the  operator  console  should  be  kept 
free  from  any  feature  required  to  satisfy  the  needs  of  other  working 
groups  such  as  engineering,  control  applications  and  maintenance. 

The  operator  , however,  should  be  given  warning  concerning  abnormal 
conditions  of  the  control  equipment  so  that  he  can  initiate  certain 
actions  under  his  responsibility  or  request  the  intervention  of  other 
groups. 

Actions  that  the  operator  should  eventually  initiate  without  assistance 
from  other  groups  could  be  the  following: 

Switching  to  a redundant  communication  bus  (even  when  automatic 
switchover  facilities  arc  provided) 

Program  downloading  (e.g.,  via  cassette  or  diskette)  associated 
with  the  data  base  of  his  console 

- Realocation  of  tasks  of  a failed  module 

Restart /reload  of  other  processors  belonging  to  the  distributed 
control  system. 

Warnings  to  the  operator  about  the  status  of  the  control  equipment  should 
be  normally  general  in  nature  but  clear  enough  to  let  him  evaluate  the 
effect  of  a failure  on  the  process  and  the  corrective  action  he  needs  to 
take  to  recover  from  such  failure  (not  to  fix  the  failed  equipment). 
Examples  of  such  warnings  could  be: 

bad  input  (normally  controlled  output  freezes  at  last  value) 

- failure  of  a device  locally  or  remotely  installed,  used  either 
for  control  or  data  acquisition  and  list  of  tags  affected  by  such 
failure. 
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Extensive  on-line  diagnostics  are  expected  to  be  provided  throughout  the 
system  but  should  be  displayed  elsewhere  (e.g.,  "maintenance"  console, 
local  diagnostic  panels,  etc.) 

• In  general,  the  operator  should  be  able  to  communicate  with 

- DDC  control  functions 

- Supervisory  control  functions 

- Back-up  instrumentation  (if  and  when  used) 

- Historical  data  base 

The  console  must  include  all  functions  of  currently  used  analog 
back-up  panels  (even  in  the  eventuality  that  such  panel  is  still 
provided) . 

• The  console  pr  cedures  must  be  simple  and  logical  so  that  operators 
should  be  frecu-to  the  maximum  extent  possible-from  thinking  about 

the  mechanics  of  performing  console  functions.  This  should  allow  them 
to  give  maximum  attention  to  process  operations. 

• Some  functions,  such  as  manual  shutdown  pushbuttons  and  critical 
alarms  will  most  likely  continue  to  be  implemented  via  hardwired 
techniques  (totally  separated  from  digital,  shared  line  techniques). 
These  functions  should,  however,  be  arranged  conveniently  and  integrated 
into  the  console  area. 

Screens 


• It  is  envisaged  that,  because  of  considerable  lead  over  com- 
peting technologies  , CRT's  may  continue  to  be  used.  This 
specification,  however,  does  not  reject  the  use  of  different 
technologies  provided  that  they  offer  display  capabilities  (in  terms, 
of  resolution,  color,  number  of  characters,  etc.)  at  least  similar 
with  high  quality  CRT's,  available  today. 

• The  basis  for  this  specification  are  high  resolution,  15"  diagonal, 
color  CRT.  Other  sizes  are  not  excluded  but  it  should  be  kept  in 
mind  that  space  may  be  at  a premium  and  screen  dimensions  should  be 
compatible  with  the  requirements  of: 

- Optimum  viewing  distance 

- Operator's  reach 

- Total  number  of  screens 

• It  is  expected  that  the  minimum  viewing  distance  will  be  28"  (approx. 

71  cm).  Under  this  viewing  condition  the  operator's  "span  of  attention" 
(5  deg.  visual  angle)  corresponds  to  2. 44  in  (6.21  cm)  measured  on  the 
screen  face. 
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This  should  be  kept  in  mind  so  that  multicharacter  labels  fit  preferential- 
ly into  this  field.  Ideally,  the  information  associated  with  a tag, 
especially  for  multiloop  formats,  should  fit  into  a screen  sector 
intercepted  by  the  5 degree  solid  cone  of  vision. 

The  numeric  word  size  associated  with  this  screen  sector  should  not 
exceed  a max.  of  12  characters  and  for  textually  coded  information 
should  not  exceed  a max  of  ft  characters. 

• The  character  size  should  be  compatible  with  a viewing  distance  at  least 
1.5  times  the  minimum  one  specified  above.  Compatibility  of  display 
resolution  and  address ibil ity  of  the  driving  electronics  is  essential. 
Whenever  CRT's  are  used,  the  addressibil ity  of  the  electronics  should 

be  in  general  better  than  that  of  the  display  so  that  dots  can  be  writ- 
ten to  overlap  one  another  in  a manner  that  makes  them  look  like  lines 
and  not  a string  of  dots.  Character  size  should  not  exceed  0.5  cm  (0.2  in.) 

• Display  loading  (X  of  active  screen  area)  should  be  optimized  around 
25X.  In  addition,  change  of  status  (e.g.,  alarm  condition),  sele- 
tion  of  a group  of  data  by  the  operator  (such  as  a loop)  or  manip- 
ulation oi  certain  parameters  (e.g.,  set  point,  output)  should  be  always 
highlighted  on  the  screen  (e.g.  intensification  of  characters,  "reverse 
video"  etc.).  Blinking  should  be  limited  to  indicate  alarm  conditions 
and  should  be  associated  with  a portion  of  the  displayed  information 
that  is  either  added  when  the  alarm  condition  appears  or  has  secondary 
importance  in  relation  to  the  text  being  highlighted  (e .g. , in  a horizontal 
text  orientation  of  an  alarm  message,  the  tag  and  description  should 
only  be  intensified;  blinking  may  be  associated  only  with  say  the  time 
of  occurance-appear ing  on  the  right  of  t ho  text-or  with  a symbol  or 
character,  such  as  an  asterisk,  added  to  either  side  of  the  text).  It 
should  be  remembered  that  blinking  the  entire  text,  makes  it  difficult 

to  read.  Blinking,  however,  of  a symbol  on  a graphic  presentation  (line, 
pump,  valve,  etc.)  is  perfectly  acceptable  and  may  certainly  be  used. 

In  general,  color  coding  should  also  be  used  to  further  highlight  infor- 
mation of  interest  and  assist  the  operator  in  focussing  his  attention 


Response  Times 

There  are  several  response  times  associated  with  the  operation  from 
"shared"  type  display  devices.  These  are  discussed  below: 

• Call-up  of  new  displays 

Basic  operating  displays  such  ns  overview  at  unit  level,  multitag  control 
displays  and  alarm  displays  should  have  response  times  of  less  than  1/2 
second  for  new  display  request.  This  means  that  the  new  display  will  ap- 
pear on  the  screen  in  complete  format  within  1/2  sec. 


Other  displays,  such  as  overviews  at  multiunit  level,  multitrend  (plot) 
displays  or  graphic  presentation  of  process  diagrams  may  ha  ve  sotrewha  t 
slower  response  time.  This  time  should  normally  be  between  1 and  2 sec. 
During  periods  of  high  system  loading,  a response  time  in  the  range  of 
2 to  3 sec.  will  still  be  acceptable  but  this  figure  should  not  be  con- 
sidered as  design  objective.  Whenever,  the  response  time  exceeds  1 sec., 
either  an  immediate  feedback  should  be  given  to  the  operator  (so  that 
he  knows  his  request  is  being  processed")  or  the  display  should  be  built 
gradually  and  completed  within  the  stated  response  time. 

• Updating  of  displayed  information 

Ideally,  updating  of  the  displayed  information  should  be  consistent  with 
the  frequency  of  tag  processing.  For  example,  from  an  operator's  point 
of  view  there  is  no  point  in  retrieving  and  displaying  a piece  of  info- 
mation  say  every  2 sec.,  if  this  information  is  processed  every  16  sec. 

On  the  other  hand,  syncornization  of  display  updating  with  the  frequency 
of  tag  processing  may  add  considerable  complexity  and  should  be  considered 
in  connection  with  the  other  components  of  the  control  system  and  only  if 
there  are  advantages  to  be  gained  in  terms  of  utilization  of  available 
resources . 

Display  updating  in  the  range  of  4 to  5 sec.  has  been  found  generally 
acceptable  even  for  tags  being  processed  several  times  during  this  time 
interval.  If  a fixed  update  frequency  is  used  for  all  displayed  informa- 
tion, the  above  figures  should  be  used. 

• Response  time  under  direct  manipulation 

During  the  "interactive"  mode,  operators  may  change  certain  parameters 
associated  with  a tag  such  as  for  example  change  the  control  mode, adjust 
manually  a set  point  or  the  output  signal  to  a control  valve. 

Whenever  the  operator  manually  changes  an  adjustable  parameter,  the  new 
value  of  this  parameter  should  be  updated  on  the  screen  within  1/2  to  1 
sec.  of  the  change.  These  new  values  should  represent  confirmed  "echoes" 
transmitted  back  from  the  device  that  will  process  the  requested  change. 

The  need  for  executing  the  requested  change  within  the  above  stated  inter- 
val i6  a more  complex  matter  and  may  not  be  generalized  for  all  cases. 

In  general  operator  initiated  actions  for  tags  in  automatic  control  such 
as  opening  a cascade  link  or  changing  the  hierarchical  level  of  control 
implementation  (e.g.,  passing  from  automatic  control  performed  by  the 
"back-up"  instrumentation  to  automatic  control  performed  by  the  computer 
or  vice-versa)  should  be  executed  immediately  by  the  device  that  process 
the  tag.  The  same  holds  true  when  transferring  a control  tag  to  manual 
mode.  On  the  other  hand,  a set  point  change  may  cither  be  registered  by 
the  device  processing  the  tag  , to  be  used  later  on  when  the  tag  is  scheduled 
to  be  processed,  or  cause  the  tag  to  be  processed  immediately.  The  latter 
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case  Is  not  required  if  the  tag  processing  frequency  matches  the  lag 
in  system  response  and  should  have  no  effect  on  human  operators  (in 
terms  of  "growth  of  uncertainty")  since  their  behavior  has  been  found 
to  quickly  adjust  to  the  particular  system  lag. 

For  control  tags  transferred  to  manual  mode,  operator  initiated  changes 
concerning  the  output  should  always  be  executed  immediately,  independ- 
ently of  any  preassigned  frequency  for  tag  processing. 

In  addition,  under  manual  control  of  a process  variable  operators'  un- 
certainty increases  and, consequently,  also  their  need  for  more  frequent 
process  feedback  especially  when  the  variable  being  manipulated  is  near 
the  limits  of  its  tolerance  range.  The  same  holds  true  when  in  an  emer- 
gency the  operator  fully  shuts  a valve  and  expects  an  immediate  feedback 
from  the  process,  to  verify  if  his  control  action  had  the  desired  effect. 
In  manual  mode,  therefore,  and  under  direct  manipulation  of  the  outputs, 
the  process  inputs  associated  with  control  tags  directly  outputting  to 
the  process  should  be  updated  on  the  screen  at  least  every  second. 

Ideally,  the  frequency  of  this  updating  needs  only  to  match  the  system 
time  lag  and  the  rate  of  growth  of  uncertainty  of  the  operator  for  each 
condition.  However,  quite  extensive  knowledge  of  the  factors  contributing 
to  uncertainty  is  needed  to  form  even  approximately  realistic  estimates. 
The  above  figure,  therefore , a 1 though  not  opt imi zed  for  "minimum  sampling" 
conditions,  will  offer  the  freedom  of  unrestricted  visual  sampling. 


Safety  Interlocks  and  Pacing 

It  is  envisioned  that  several  interlocks  will  continue  to  be  used, 
either  to  prevent  accessibility  to  certain  parameters  or  to  force  the  operator 
to  use  certain  console  procedures. 


Tills  aspect  should  l>e  carefully  considered  since  it  has  considerable 
effects  on  the  human  operator.  The  operator  is  said  to  be  "paced"  by  the  machine 
if  he  has  little  choice  of  what  to  do,  how  to  do  it  and  when  to  do  it.  On  the 
other  hand,  the  operator  is  said  to  he  "pacing"  the  machine  if  he  decides  on 
his  own  what  to  do,  how  to  do  It  and  when  to  do  it.  This  leads  to  the  follow- 
ing considerations: 

• To  the  maximum  extent  possible,  rigid  procedures  should  be  avoided  by  pro- 
viding multiple  choices  for  the  execution  of  a task. 

• The  operator  should  be  given  the  maximum  possible  freedom  of  building,  al- 
tering or  adding  displays  as  well  as  changing  the  way  they  are  cross-re- 
ferenced . 

• Safety  Interlocks  should  never  be  designed  as  unmoveable  blocks  and  their 
commissioning  should  he  left  to  the  user. 


• Whenever  the  operator  uses  the  wrong  procedure  causing  the  activation 
of  an  interlock,  a message  should  he  generated  telling  him  not  just 
that  he  made  an  error  hut  also  what  to  do  or  why  it  Is  not  allowed  to 
proceed.  For  example,  if  changing  of  alarm  limits  is  protected  against 
unauthorized  changes,  the  message  on  the  screen  should  not  simply  say, 
"illegal  entry"  but  should  also  explain  why  it  is  illegal,  as  for  ex- 
ample, "password  is  needed"  or  "access  interlocked  by  key".  The  above 
consideration  should  also  be  applicable  to  the  design  of  other  consoles 
such  as  the  engineer's  console,  etc. 


Hard  Copy 

It  should  be  possible  to  obtain  at  any  time  a hard  copy  of  any  dis 
play  information.  This  hard  copy  should  be  preferentially  an  exact  replica 
of  the  information  being  displayed  on  the  screens. 

Time  Indication 

In  general  the  time  and  date  should  be  displayed  with  each  display 

format . 


Reports.  Logs,  History  and  Messages 

In  general,  logs  , reports , hi  story  and  various  messages  (such  as  histori- 
cal data,  hourly  averages,  daily  averages,  daily  reports,  etc.)  should  be  stored 
and  generated  by  other  devices  of  the  distributed  system.  The  user  should  have 
the  ability  to  generate  his  own  formats  to  suit  his  specific  needs  using  separate 
alphanumeric  peripherals. 

Unless  specifically  stated  in  this  specification,  the  above  data  are 
not  Intended  to  be  displayed  on  the  operator  console's  screens.  The  operator, 
however,  should  be  able  to  request  their  presentation  from  his  keyboard  so  that 
they  can  be  displayed  via  other  peripherals  of  the  system,  such  as  high  speed 
printers . 


The  description  and/or  definition  of  the  various  types  of  logs,  re- 
ports, etc.,  is  outside  the  scope  of  this  speci fication  and  in  general  is  parr 
of  the  functional  description  of  the  distributed,  multi  processor  system.  As 
far  as  this  specification  is  concerned,  it  will  only  address  console  related 
actions  that  should  be  logged,  the  general  nature  of  messages  to  be  presented 
to  the  operator  and  the  display  format  of  relatively  short  term  historical  data. 

• Console  related  logs 

The  purpose  of  these  logs  is  to  enable  the  reconstruction  of  events  that 
had  involved  the  human  operator.  In  summary,  are  the  following: 
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- General  Alarm  Lag 

Any  alarm  event,  Including  changes  of  alarm  limit,  inhibition  of 
alarms  or  setting  of  alarm  conditions  to  "invalid"  status  should  he 
logged  in  sequence  and  kept  in  bulk  memory.  This  log  should  retain 
the  last  5000  events.  A subset  of  this  log  should  be  available  for 
display  on  the  console's  screens  (See  "display  characterist ics"  for 
details) . 

- Console  Log 

All  keyboard  initiated  changes  or  entries  should  also  be  logged  in 
sequence.  This  log  should  retain  as  a minimum  the  last  3000  key- 
board initiated  actions  for  each  console. 


DISPLAY  CHARACIT.K1ST1CS 


Generation.  Processing  and  Presentation  of  Alarms 

Alarms  are  in  general  a form  of  condensed  information  that  is  pre- 
sented to  the  operator  in  a manner  requiring  minimal  search  and  identification, 
l.enghty  messages  are  not  alarms  and  should  never  be  used  to  alert  operators 
of  critical  conditions.  Alarms  should  be  interpreted  at  a glance  and  shall 
not  require  study  of  the  text  or  extensive  search  by  the  operator. 

• Alarm  processing  for  display  purpose 

- It  should  be  possible  to  assign  up  to  2 different  levels  of  priority 
to  each  alarm  (whether  indirectly  or  directly  generated)  for  display 
purpose  as  follows: 

Priority  1:  Critical  alarms,  associated  with  immediate  identification 

of  conditions  that  may  result  in  injury  to  personal,  damage 
to  process  equipment  or  large  operating  debits. 

Priority  2:  Important  abnormal  conditions  that  must  be  acknowledged  by 
the  operator  and  assist  him  in  initiating  actions  that 
would  prevent  the  development  of  serious  upsets. 

Generally,  the  condition  being  alarmed  will  not  result  in 
an  inmodinte  disaster  on  the  unit  and  required  reaction 
may  occasionally  be  slower  than  reaction  to  Priority  1 
alarms. 

For  display  purpose,  all  other  abnormal  conditions  to  be  displayed 
should  be  considered  as  "messages",  discussed  later  on  in  this  spec l - 
f icat ion. 


I 


-7'i3- 


- It  should  bo  noted  that  other  alarm  priorities  may  be  associated  with 
tag  processing  but  these  should  not  be  confused  with  the  display  pr i - 
or i t ie s mentioned  above.  The  purpose  of  alarm  priorities  associated 
with  tap  processing  is  outside  the  scope  of  this  specification,  hut, 
in  general,  they  may  be  used  to  determine  which  condition,  If  any, 
should  be  displayed  to  the  operator.  It  should  be  also  noted  that 
alarm  conditions  having  different  processing  priorities  may  very  well 
have  the  same  "display"  priority,  as  defined  in  this  specification. 

- During  configuration  of  the  data  base,  alarm  conditions  associated  with 
any  tag,  should  be  individually  coded  for  display  priority  level. 

- It  should  be  possible  to  change  alarm  priorities  from  the  console's 
keyboard  on  a single  tag  basis.  Provisions  to  prevent  free  access 
via  interlocks  should  be  included,  but  the  decision  to  activate  these 
interlocks  should  be  left  to  the  user. 

- Alarm  priority  should  affect  alarm  presentation  in  accordance  with  the 
guidelines  listed  below  (see  alarm  presentation). 

- Alarm  limits,  whenever  adjustable,  will  be  accessible  from  the  console's 
keyboard.  The  same  holds  true  for  adjustable  dead-hands  (or  time  delay) 
associated  with  the  change  of  state  of  non-ad justable  contacts  (such  as 
field  switches) . 

- Alarm  inhibition  should  be  possible  for  any  alarm,  independent  of  its 
priority,  either  individually  or  in  groups. 

- Any  change  of  alarm  limits  or  alarm  inhibition  should  be  automatically 
logged.  This  log  should  be  available  for  display  on  a screen  at  any  time 
and  should  retain  a history  of  the  last  30  changes  or  at  least  sufficient 
enough  to  cover  a period  of  48  hours.  Provisions  should  be  made  to  clear 
this  log  from  the  keyboard. 

- Modification  of  alarm  limits,  inhibition  of  alarms  and  clearing  of  the 
alarm  status  log  mentioned  above,  should  be  in  general  protected  by  in- 
terlocks to  prevent  free  access.  Activation  of  these  interlocks,  however, 
should  be  at  the  option  of  the  user. 

Alarm  messages 

Any  abnormal  condition  that, if  not  acknowledged  by  the  operator,  may  affect 
optimum  control  of  the  units  or  may  lead  in  time  to  priority  2 or  priority 
1 conditions  should  be  considered  as  "alarm  message". 

These  messages  may  have  variable  formats  to  suit  the  specific  type  of  info- 
mation  to  be  presented  to  the  operator  and  in  general  they  should  not  be 
limited  to  text  forms. 

A 1 arms  messages , should  he  used  preferentially  to  indicate  to  the  operator 
what  sort  of  action  is  recommended  or  what  is  the  predicted  effect  and  not 
just  describe  the  condition  that  is  in  abnormal  status. 
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• Alarm  generation 

Figure  3 shows  schematically  how  alarms  are  generated  in  current,  computer 
based  control  configurations  with  analog  "back-up"  instrumentation.  The 
use  of  microprocessor-based,  digital  instrumentation  may  introduce  new 
options  which  may  or  may  not  be  used,  depending  on  the  degree  of  software 
integration  between  computers  and  instrumentation  and  the  use  of  the  instru- 
mentation data  base. 

It  should  be  assumed  that  in  future  control  configurations  a certain  number 
of  process  alarms,  generated  by  on-off  type  sensors,  may  still  be  handwired 
to  independent  alarm  logic  cards  driving  dedicated  windows.  These  alarms, 
however,  should  also  be  displayed  on  the  console's  screens.  In  general,  con- 
tact input  associated  with  process  alarms  could  be  brought  into  the  console 
either  via  a digital  I/O  box  connected  to  the  medium  speed  bus  or  the  high 
speed  bus  or  via  an  1/0  peripheral,  supported  directly  by  the  console  pro- 
cessor (s)  . 

It  is  expected  that  all  other  alarms  should  be  accessible  via  the  digital 
communication  subsystem,  using  the  communication  potocol  established  for 
digital  transactions  with  other  devices  connected  to  the  coimaunication 
subsystem. 

For  software  generated  alarms  by  the  distributed  multiprocessor  system, 
it  should  be  noted  that  the  information  to  be  displayed  may  be  uniquely 
determined  by  the  levels  of  priority  associated  with  tag  processing  or 
other  software  programs. 

To  the  maximum  extent  possible,  alarm  generation,  limits  and  status  (i.e., 
active  or  inhibited)  should  be  kept  in  one  location  of  the  system's  distri- 
buted data  base  and  automatically  updated  when  changes  are  made  from  any- 
where in  the  system. 

• Alarm  presentation 

As  it  has  been  pointed  out  before,  several  alarm  limits  may  be  associated 
with  a single  tag.  It  was  also  made  clear  that  not  all  these  conditions 
should  necessarily  be  presented  to  the  operator  as  alarms.  Several  may  not 
be  displayed  at  all  and  only  used  by  the  control  system  to  i:iitiate  control 
actions  or  eventually  to  generate  alarm  messages.  However,  whenever  more 
than  one  of  these  conditions  is  to  be  displayed  to  the  operator  (either  as 
an  alarm  or  as  a message),  the  presentation  should  be  consistent  and  logical 
such  as  to: 

- avoid  redundant  presentation  if  one  condition  is  the  logical  consequence 
of  another. 

- attract  the  attention  of  the  operator  to  the  more  severe  condition. 

- Inform  the  operator  about  the  validity  of  certain  displayed  conditions  if 
this  becomes  questionable  as  a result  of  another  event. 
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For  example,  if  a bad  input  is  detected  during  tag  processing  (e.g., 
transmitter  failure  causing  the  input  signal  to  drop  to  zero),  several 
other  alarm  limits  that  may  be  associated  with  this  tag,  will  be  event- 
ually violated,  such  as  low  input,  rate  of  change  or  deviation.  In 
this  case,  however,  the  detection  of  these  abnormal  conditions  is  not 
only  the  logical  consequence  of  the  first  one  (bad  input)  but  their 
validity  is  at  least  questionable.  The  only  information  that  the  oper- 
ator really  needs  is  that  there  is  a suspected  equipment  failure  and 
should  not  be  given  process  oriented  alarms  (which  in  fact  mav  not  be 
true).  Indeed,  if  an  alarm  is  associated,  say  with  the  low  input 
condition,  it  should  be  set  to  "invalid"  status  and  this  should  be  clearly 
indicated  on  all  display  formats  on  which  this  alarm  condition  may  be  shown. 

It  is  envisioned  that  a number  of  screens  (at  least  two)  will  be  normally 
used  for  displaying  alarm  conditions.  The  procedure  to  select  a screen 
for  "dedicated"  displays  will  be  discussed  later. 

(a)  Priority  1 alarms 

- Priority  1 alarms  should  automatically  appear  on  a selected  screen 
or  portion  of  this  screen  (no  operator  a on). 

- If  an  alarm  is  also  hardwired  to  a separate  alarm  system  then: 

+ this  system  should  be  either  mounted  on  the  console  or  installed 
close  to  the  console  (readily  visible). 

+ it  should  be  acknowledged  by  the  same  keys  or  pushbuttons  used 
with  the  console's  screens. 

+ it  will  not  be  affected  by  any  console  failure  mode. 

+ it  will  not  affect  the  operation  of  the  console  in  case  of  total 
or  partial  failure. 

Such  system  could  be  , for  example, a miniature  type  annunciator  panel 
(e.g.,  3/4"  x 3/4"  windows),  completely  divorced  by  the  console 
hardware  and  software  except  as  mentioned  above. 

- Alarm  message  on  the  screen  will  not  occupy  more  than  one  horizontal 
line  and  will  include  tag  I.D.,  description  of  alarm,  type  of  alarm, 
and  time  of  occurrence. 

- New  alarms  will  appear  at  the  top,  pushing  down  previous  alarms  and 
will  be  highlighted  as  described  previously  (blinking,  color  coding, 

etc . ) . 

- Alarms  will  remain  on  the  screen  when  acknowledged  and  will  disappear 
when  alarm  condition  returns  to  normal.  Empty  spaces  in  the  stack 
will  be  occupied  by  existing  alarms  that  may  be  displayed  at  that  time 
(push-up) . 
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- The  screen  (or  1 1 s used  port  ion  for  pr  ( or  1 ty  1 alarms)  should  have  a 
display  capability  optimized  for  20  alarms.  If  overflow  occurs, 
the  alarm  listing  will  continue  on  a next  page  and  this  should 
he  indicated  on  the  screen  (e.g.,  page  1 of  2). 

- If  the  same  alarm  repeats  Itself,  only  the  latest  occurrence  will 
he  retained  on  the  screen.  The  entire  sequence,  however,  should 

be  kept  in  memory  and  presented  as  alarm  lop,  on  demand  (hard  copy). 

j 

(b)  Both  priorities 

- Any  alarm  will  activate  a matrix  of  individually  address- 
able elements  such  ns  n matrix  of  backlighted  pushbuttons 
Although  this  specification  does  not  exclude  the  use  of  any 
specific  methods  to  Implement  this  matrix,  the  design 
should  meet  the  basic  functional  requirements  described  later  on  and 
must  be  consistent  with  the  design  criteria  concerning  the  interaction 
between  the  modules  of  each  console  listed  previously.  For  simplicity, 
this  matrix  is  referred  to  In  this  specification  as  "pushbutton 
matrix".  The  "pushbuttons"  of  the  matrix  may  have  other  functions 
when  the  associated  screens  are  not  selected  for  alarm  displays. 

- The  above  matrix  should  contain  a number  of  active  buttons  consistent 
with  the  alarm  data  base.  Each  button  will  correspond  to  an  alarm 
page  and  used  to  call-up  that  page  only.  A minimum  display  capacity 
of  20  alarms  per  page  should  be  provided  but  higher  densities  are  de- 
finitively desirable  when  deal  ingwith  a large  data  base.  The  buttons 
will  have  an  ISA-1  flashing  sequence  (same  as  panel  auuunicators) . 

- The  alarm  pages  will  have  the  following  characteristics: 

+ will  continuously  display  all  tags  assigned  to  the  page. 

+ will  highlight  the  tag  in  alarm  condition  (blinking,  color  coding, 

etc . ) 

+ will  indicate  the  priority  of  the  tag  in  alarm  condition,  preferably 
via  color  coding. 

+ it  wLll  be  possible  to  Inhibit  alarms,  addressing  tho  tag  on  the 
page.  Inhibited  alarms  should  he  clearly  Identified,  preferably 
both  via  textual  and  color  coding  (suggested  color:  blue). 

+ it  should  indicate  "invalid"  status  of  alarms,  again  via  textual 
and  color  coding. 
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+ it  will  indicate  the  code  or  page  number  of  multiloop  displays 
associated  with  each  alarm  as  applicable. 

+ the  format  of  each  horizontal  line  should  be  the  one  described 
for  the  priority  l alarms. 

- The  matrix  of  lighted  pushbuttons  will  act  as  "group"  alarm  dis- 
play and  will  have  realarm  features  (new  alarms  will  always 
initiate  a flashing  sequence).  Acknolwedged  alarms  will  be  in- 
dicated by  steady  lights. 

The  priority  of  the  alarm  initiating  the  alarm  sequence  will  also 
be  indicated  on  the  alarm  matrix  (same  color  coding  as  the  one  used 
on  the  screen).  Pages  contai ni ng  inhibited  alarms  should  also  be 
identifiable  at  the  "group"  alarm  matrix. 

- The  last  row  of  the  matrix  should  be  normally  associated  with 
special  function  keys.  These  keys  will  have  the  same  functions 
for  all  keyboards  and  should  normally  be  used  to  select  a screen 
for  special  purpose  displays  (e.g.,  priority  1 alarms).  One  of 
these  keys  should  be  used  for  immediate  call-up  of  the  multi  loop 
display,  which  is  logically  associated  with  the  alarm  condition. 

This  key  will  have  the  same  function  on  any  given  keyboard, 
and  will  always  call-up  on  the  corresponding  screen  the  mulciloop 
display  associated  with  the  first  unacknowledged  alarm  condition 
that  may  exist  at  that  time.  If  more  than  one  alarm  condition 
exist,  the  multiloop  display  that  will  he  called-up  will  correspond 
to  the  alarm  condition  having  higher  priority. 

- Alarms  will  be  acknowledged  by  pressing  the  corresponding  matrix 
button  or  the  above  mentioned  special  key.  The  audible  signal 
will  be  silenced  immod lately  but  the  visual  coding  associated  with 
unacknowledged  status  (such  as  blinking)  will  remain  on  the  addressed 
display  for  at  least  4 sec.  However,  it  should  be  also  possible  to 
acknowledge  priority  l alarms  appearing  automatically  on  another 
screen  from  the  keyboard  of  that  screen.  This  acknowledgement  will 
not  call-up  the  alarm  page  containing  the  same  alarm  but  will  switch 
to  acknowledge  status  the  corresponding  matrix  button(s). 

- The  alarm  condition,  whenever  is  directly  associated  with  the  pro- 
cessing of  a tag  (e.g.,  PV  of  a control  tag  exceeding  its  alarm 
limits)  will  also  he  highlighted  at  (a)  the  "overview"  display  level 
(if  contains  that  tag),  (b)  the  multi  loop  display  containing  that 
tag  and  (c)  the  single  tag  display  level. 

- If  an  alarm  condition  associated  with  a multiloop  display  occurs 
while  this  display  is  being  shown  on  nnv  screen,  the  alarm  status 

at  the  multiloop  display  level  should  also  be  highlighted  (blinking, 
color  coding  etc.)  Selecting  a ny  loop  on  this  display  will  acknow- 
ledge the  alarm,  and  no  further  acknowledgement  will  ho  required, 
provided  that  other  alarm  conditions  do  not  exist. 
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- Similarly,  If  the  alarm  condition  occura  while  an  overview  dis- 
play containing  the  associated  tag  Is  being  displayed  (on  any 
screen)  the  above  condition  should  be  indicated  by  blinking  the 
group  containing  the  tag  in  question.  The  alarm  will  again  be 
acknowledged  when  passing  from  the  "overview"  level  to  the  multi- 
loop level  with  the  same  procedure  mentioned  before  (audible 
signal  silenced,  visual  coding  changing  to  acknowleged  status 
after  4 sec.) 

- The  priority  assigned  to  each  alarm  condition  will  be  indicated 
not  only  visually  but  also  audibly  (i.e.,  different  audible 
signals  for  different  alarm  priorities). 

Ideally,  it  should  be  possible  to  adjust  the  frequency,  tone  and 
loudness  of  the  audible  signals. 

Each  console  should  have  clearly  distinguishable  audible  signals 
from  other  consoles  In  the  same  control  room.  Those  signals  should 
bo  associated  with  each  console's  "normal"  data  base. 


• Presentation  of  alarm  messages 

- It  should  be  possible  to  display  these  messages  on  any  screen  by  using 
the  keyboard  associated  with  that  screen.  The  existanco  of  a message 
waiting  to  he  displayed  should  he  visually  indicated  on  each  keyboard. 
In  general,  audible  signals  should  he  avoided  for  messages.  Call-up 
should  he  pre f ferent ia 1 ly  via  single  action. 

- If  a split  screen  is  vised  for  priority  1 alarms,  the  lower  portion  of 
this  screen  may  he  used  to  display  alarm  messages. 

- In  general,  messages  should  not  he  displayed  automatically  (operator 
cell-upl.  It  should  be  possible,  however,  to  differentiate  between  gen- 
eral alarm  messages  and  messages  associated  with  equipment  failures 
(lists  of  affected  tags,  etc.). 

• Invalid  Alarms 

- Invalid  alarm  conditions  should  he  indicated  on  all  display  formats  on 
which  such  alarm  condi t Tons  are  normally  displayed.  In  addition,  a 
special  log,  listing  all  invalid  alarm  conditions  (not  to  he  confused 
with  inhibited  alarms)  existing  at  any  time  should  be  maintained  and 
displayed  on  request. 

- The  existanco  of  invalid  alarms  should  be  preferentially  indicated  on 
the  alarm  matrix  (same  color  coding  os  the  one  used  on  the  screen).  If 
no  other  warning  is  available,  the  alarm  condition  being  invalidated 
should  initiate  an  alarm  sequence  (to  be  acknowledged  as  with  valid 

a l arm  cond i t 1 ons) . 
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Summarv  of  Alarm  Handling 

In  conclusion  the  main  characteristics  of  alarm  processing  and 
presentation  can  be  summarized  as  follows: 

• The  alarm  pushbutton  matrix  (group  alarm)  and  the  associated  alarm 
pages  will  be  equivalent  to  scanning  panel  mounted  annunciators. 

Pattern  recognition  is,  therefore,  maintained  at  both  the  matrix 
and  alarm  page  level. 

• The  priority  of  the  alarm  condition  will  always  be  indicated  both 
visually  and  audibly. 

• Color  coding  should  be  extensively  used  to  highlight  alarm  conditions 
together  with  other  visual  coding  such  as  intensification  and/or 
blinking. 

• Alarm  conditions  may  appear  in  several  formats  and  should  be  acknowledged 
in  a logical  fashion,  avoiding  unnecessary  steps. 

• Maximum  flexibility  should  be  retained  in  assigning  to  any  given  screen 
the  role  of  displaying  priority  1 or  prearranged  alarm  pages.  Time  of 
alarm  occurrence  will  be  indicated  in  both  type  of  displays. 

a Immediate  access  to  the  appropriate  type  of  display  for  verification 
or  action  will  ensure  minimum  time  spent  for  search  and  identification. 

• Redundant  presentation  of  alarm  conditions  should  be  avoided  if  one 
condition  is  the  logical  consequence  of  another. 

• Invalid  alarm  conditions  should  be  clearly  indicated  as  such. 

Overview  Capability 

• Deviation  type 

- Surveillience  of  a large  number  of  variables  should  be  via  "over- 
view" type  displays.  The  basic  overview  display  should  consist  of 
prearranged  groups  of  variables  - corresponding  to  multitag  (multi- 
loop) formats  - that  will  be  displayed  in  dedicated  sectors  of  the 
screen.  The  parameter  used  should  be  the  deviation  of  a variable 
from  its  set-point  or  target. 
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The  deviations  should  be  shown  ns  vertical  bars  extending  from 
a horizontal  (zoro-deviat  ion)  line.  The  maximum  number  of 
variables/group  should  correspond  co  the  max  number  of  tags  that 
should  be  assigned  to  multitag  formats.  This  number  should  be  pre  f- 
fcrably  8 but  could  be  as  high  as  I(>  provided  that  viewing  clarity  is 
not  compromised  and  that  the  multitag  formats  contain  all  the 
information  (see  multitag  displays)  without  overloading  the  screen. 

It  should  be  possible  to  assign  any  multitag  group  to  a deviation  type 
display  independently  ol'  its  sequential  number  in  the  console's  data 
base.  The  procedure  tor  building  or  modifying  this  overview  display 
should  be  simple  and  available  from  the  keyboard  for  online  reconfig- 
uration. The  % in  deviation  required  to  produce  a given  excursion 
should  he  individually  programmable  for  each  variable  from  0 to  1007.. 

A normalized  band  of  acceptable  deviation  should  be  clearly  identified. 
Deviations  exceeding  this  hand  will  cause  the  corresponding  group  to 
change  display  color  (e.g.,  from  green  to  amber).  However,  none  of  the 
characteristics  ot  alarm  status  (such  as  blinking  etc.)  will  accompany 
this  warning  unless  the  exceeded  limit  happens  also  to  be  an  alarm  limit 

The  "zero  deviation"  (reference)  lines  should  he  clearly  separated  one 
from  another  to  indicate  each  group.  Within  a group,  this  line  should 
he  further  subdivided  in  smaller  portions  such  that  each  portion  should 
contain  no  more  than  4 variables. 


It  should  be  possible  to  assign  to  any  screen  the  role  of  displaying 
deviation  type  "overview"  displays  either  by  using  the  standard  key- 
board or  by  using  one  of  the  special  function  keys  (last  row  of  push- 
button matrix).  In  this  case  the  screen  will  "lock"  to  the  "overview" 
display  unless  the  key  is  again  depressed.  The  key  should  be  back  il- 
luminated with  the  light  "on"  in  the  locked  position. 

Each  group  on  the  overview  display  will  be  addressable  via  the  push- 
button mat  rix  dese  i i bed  before.  In  this  case,  the  active  keys  should 
he  used  to  call-up  each  group  in  the  format  described  under  mult itag 
displays . 

If  the  screen  is  "locked",  the  multitag  format  should  normally  appear 
on  another  screen  assigned  specifically  to  mult itag  displays  (again 
via  a special  function  key)  ot  to  any  "unass igned"  screen  by  default 
option.  Otherwise,  the  multitag  display  will  appear  on  the  same  screen, 
replacing  the  overview  display. 

Roth  the  groups  on  the  screen  and  the  pushbuttons  of  the  matrix  should  he 
numbered  for  easier  (dent i f i cat  ion  - Group  description  will  only  appear 
on  the  screen  (approx.  8 char.ictei  doser  i pt  ions/group) , not  on  the  matrix. 
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- As  mentioned  be  fore , certain  alarm  conditions  will  also  appear  on 
the  overview  display. 

Any  group  containing  a tag  in  alarm  condition  will  be  highlighted 
(blinking,  change  of  color  etc.)  The  corresponding  pushbutton  on 
the  matrix  will  initiate  an  ISA-1  flashing  sequence. 

- The  deviation  type  "overview"  is  intended  for  the  "unit  surveillance" 
operating  mode.  Its  overview  capability  may  contain  250-350  key 
variables,  but  should  be  optimized  for  320  variables.  The  upper 
limit  should  not  exceed  400  variables. 

- At  least  two  pages  should  be  available  at  this  level  of  display, 
selectable  on  demand.  However,  more  pages  may  be  required,  depending 
on  the  size  of  the  data  base. 

• Bar  graph  type 

- This  overview  display  is  mainly  intended  for  "unit  monitoring"  and  the 
level  of  detail  should  be  between  the  deviation  type  "overview"  and  the 
multitng  format. 

- This  display  should  be  optimized  for  64  tags  displayed  as  groups  of  vertical 
bars  representing  the  input  (measured  or  calculated).  The  set  point  (or 
target)  and  the  operating  mode  tor  control  tags  should  also  be  indicated  on 
this  format.  The  groups  should  appear  in  preassigned  sectors  of  the  screen 
addressable  via  a set  of  dedicated  keys  that  will  also  be  used  to  address 
the  individual  tags  on  multitag  displays.  The  addressed  group  should  bd 
displayed  in  the  format  described  under  multitag  displays. 

- Alarm  conditions  will  also  be  shown  at  this  level  of  display  (highlighted 
by  color  coding,  blinking,  etc.) 

- The  alarm  condition  will  also  be  acknowledged  when  a group  is  addressed 
via  this  set  of  selection  keys. 

- At  least  20  pages  should  be  available  at  this  level  of  display,  but 
eventually  additional  capacity  may  be  needed,  depending  on  the  size 

of  the  data  base.  Biderectional  "paging"  should  be  possible  via  paging 
keys. 

- It  is  expected  that  a certain  number  of  pages  should  have  a logical 
association  with  the  grouping  of  tags  used  in  the  deviation  type  over- 
view. (i.e.,  the  same  groups  of  tags  arranged  i n the  same  numerical 
sequence).  In  general,  however,  this  association  should  not  be  rigid 
and  complete  flexibility  should  be  left  to  the  user  to  arrange  the 
grouping  of  tags  in  any  desired  way.  The  console  software,  however, 

sh  ould  allow  the  option  of  group  association  between  the  two  hierarchial 
overview  levels,  such  that  group  allocation  for  one  is  at  the  same  time 
implemented  for  the  other. 

In  general,  the  display  capacity  at  this  hierarchial  overview  level  should 
exceed  the  display  capacity  at  the  deviation  overview  level. 
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- The  library  of  pages  at  the  "bar  graph"  overview  level  should  also 
be  addressable  via  the  pushbutton  matrix.  The  matrix  will  automati- 
cally become  a page  directory  whenever  the  associated  screen  is  dis- 
playing this  overview  format.  The  active  buttons  should  be  clearly 
identified  and  should  maintain  a logical  relationship  with  the  ar- 
rangement used  for  the  "deviation"  type  overview  whenever  the  two 
hierarchical  overview  levels  are  associated  as  mentioned  before. 
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- It  should  be  possible  to  use  any  "unassigned"  screen  for  displaying 
this  overview  format  using  the  associated  keyboard.  No  special 
function  key  i6  required  to  lock  the  screen  to  this  overview  level. 

- Call-up  of  trend  displays  should  also  be  possible  vis  "display 
association"  with  other  display  formats  (see  multitag  and  trend 
formats) . 

Multitar,  formats 

• Thi6  display  format  is  intended  to  be  the  main  working  format  for  "in- 
teractive" and  "emergency"  modes. 

• The  tags  should  be  presented  in  digltal/bar  graph  combination  format, 


• The  tags  sha 1 1 be  addressable  by  a set  of  dedicated  keys,  one  for  each 
tag  and  located  in  such  a way  as  to  make  the  correspondance  between  the 
sector  of  the  screen  occupied  by  a tag  and  the  key  itself,  unique  and 
unmistakable . 

• As  a minimum  the  following  information  should  be  shown  in  the  graphic 
portion  of  the  display: 

- Input  (vertical  bar  graph) 

- Output  (vertical  bar  graph) 

- Setpoint  or  target  (vertical  bar  graph  or  horizontal  marker) 

The  shape  of  these  bars  should  be  clearly  di f ferent iated  so  that  visual 
intei'pretation  of  the  displayed  parameter  is  facilitated.. 

In  general,  alarm  limits  (if  applicable)  should  not  be  displayed  on  this 
format  except  upon  request.  If  these  data  are  superimposed  on  the  main 
graphic  portion,  they  should  be  presented  in  such  a way  as  neither  to 
mask  nor  confuse  the  displayed  information.  The  superimposed  information 
should  be  visible  as  background  by  using  appropriate  display  techniques 
such  as  low  intensification  and/or  dark  color.  For  superimposed  data, 
the  presentation  should  be  as  follows: 

- Input  alarm  limits  (horizontal  markers  or  vertical  bar  next  to  the  input). 
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- Output  limits  (horizontal  markers) . 

- Set  point  limits  (horizontal  markers  or  vertical  bar,  complementing 
the  set  point  presentation,  i.e.,  if  the  set  point  is  shown  as  hori- 
zontal marker,  the  limits  should  be  shown  as  vertical  bar  and  vice- 
versa)  . 

As  a minimum  the  following  Information  should  be  shown  in  the  digital 
portion  of  the  display: 

- Tag  I.D.  (6  alphanumeric  characters,  max.)’ 

- Description  (8  characters  - see  also  footnote). 

- Engineering  units  (5  characters) 

- Input,  expressed  in  eng.  units  (7  characters  max.  including  decimal  point 
and  sign) . 

- Set  point  or  target  expressed  in  eng. -units  (same  as  input). 

- Ratio  coefficient  or  bias  coefficients  (6  characters  when  applicable). 

- Output  in  eng.  units  (7  characters,  only  when  cascading  a secondary  loop). 

- Output  in  7.  (6  characters,  including  decimal  point  and  sign). 

- Operating  mode  (Auto,  Manual,  Cascade,  Computer). 

- Back-up  function  (if  and  when  applicable). 

The  following  information  should  also  be  indicated  on,  or  easily  deducted 
from  the  display  by  using  symbolic  coding  (shape)  or  color  coding  or  other 
appropriate  techniques: 

- The  provenience  of  the  set  point  for  cascaded  control  tags,  (such  as  from 
a supervisory  program) . 

- The  degree  of  freedom  for  parameter  manipulation  under  current  operating 
mode. 

• The  graphic  portion  of  the  multitag  format,  should  be  replaceable  on  demand 
by  a deviation  type  graphic  display.  The  deviation  should  be  shown  as  a 
vertical  bar,  extending  in  two  opposite  directions  from  a reference  (i.e., 
zero  deviation)  line. 


Note:  A full  description  (24  characters  max.)  should  be  usually  provided.  This 
full  description,  however,  may  only  appear  at  a preassigned  screen  area 
when  a tag  is  selected,  in  order  to  keep  the  rest  of  the  display  "clean". 


• The  lower  portion  of  the  screen  should  be  used  to  indicate  the  associated 
displays  with  the  one  being  currently  displayed. 

At  least  up  to  4 associated  displays  may  be  used  in  connection  with  any 
given  multitag  display.  The  associated  displays  can  have  any  of  the  fol- 
lowing formats: 

- Multitrend 

- Bar  graph  overview 

- Multitag 

A set  of  4 dedicated  keys  should  be  used  to  call-up  any  one  of  the  "associated" 
displays.  The  associated  displays  should  be  normally  displayed  on  those 
screens  assigned  to  trend  displays  and  by  default  option  to  any  "unassigned" 
screen.  However,  they  could  also  replace  the  multitag  display  on  the  screen 
being  used  for  their  call-up  if  the  operator  chooses  so.  For  this  purpose 
a 5th  key  should  be  used  to  lock  or  unlock  the  screen  from  the  display  being 
currently  displayed.  This  locking  function  should  only  be  applicable  in 
connection  with  the  presentation  or  "associated  displays".  A 6th  key  should 
be  provided  to  allow  immediate  return  to  the  "previous"  display.  The  "re- 
turn to  previous  display"  key  should  be  always  active  and  should  apply  to  all 
type6  of  display  formats. 

• Any  alarm  condition  associated  with  a tag  should  be  highlighted  directly 
on  this  display  format.  The  preferred  method  should  be  to  associate  the 
alarm  condition  with  the  graphic  portion  by  highlighting  the  parameter 
causing  the  alarm;  the  digital  portion,  however,  can  also  be  used. 

• Shared  keys  can  be  used  for  mode  changes,  set  point,  output  etc.,  but  they 
should  be  kept  well  separated  from  any  other  cluster  of  keys. 

• Changing  of  set  point  and  output  should  be  possible  by  any  one  of  the  fol- 
lowing methods: 

- Slow  ramping  ( increment /decrement  key) 

- Fast  ramping  (separate  increment/decrement  keys) 

- Full  value  (via  alphanumeric  portion  of  keyboard) 

Full  value  changes  should  be  shown  on  the  screen  next  to  the  previous  value 
and  after  visual  confirmation  by  the  operator  should  be  entered  ("enter" 
key). 
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• The  multitag  displays  should  also  be  : 

- Configurable  from  the  console's  keyboard  (add,  delete  or  change  a tag) 
via  simple  procedures  so  that  operators  can  build  or  change  them  as 
they  wish. 

- Listed  in  6peclal  formats  (library). 

- Identified  by  general  description  and  numbered. 

• The  number  of  multitag  pages  to  be  provided  should  be  consistent  with 
the  size  of  the  data  base  and  as  a minimum  should  cover  the  total  number 
of  control  and  information-only  tags,  including  calculated  tags.  In 
addition,  a certain  spare  capacity  should  be  provided  to  be  used  by  the 
operators  to  build  displays  of  their  own  choice  as  conditions  may  dictate. 

e Paging  (both  directions)  should  be  provided  (same  keys  as  for  bar  graph 
overview) . 

e All  multitag  displays,  whether  corresponding  to  overview  groups  (call-up 
via  push  button  matrix)  or  not,  should  be  addressable  for  call-up  at  any 
time  via  the  console's  keyboard.  The  procedure  should  involve  one  func- 
tion key  and  the  alphanumeric  portion  of  the  keyboard. 


Multi  tag  Formats  For  On-Off  Control 

Control  of  pumps,  MOV's  and  other  two  state  control  devices  will 
be  normally  from  a different  display  format  having  the  following  basic  charac- 
teristics; 

• Both  states  should  be  indicated  by  textual,  symbolic  and  color  coding 
(such  as,  for  example,  two  squares,  labeled  and  color  coded)  appearing 
on  the  graphic  portion.  The  digital  portion  may  include:  equipment  tag 
number,  rpra,  amps,  output  pressure,  suction  pressure, etc.  Except  for  the 
equipment  tag  number,  other  information  may  or  may  not  be  displayed  but 
provisions  should  be  made  to  allocate  appropriate  screen  space  for  their 
Inclusion  if  applicable. 

• Intermediate  state  should  be  indicated  with  both  states  activated  (e.g., 
both  symbols  colored) . 

• Color  coding  should  be  in  general  as  follows; 

- Green  : equipment  running  (pump,  mixer  etc.);  valve  open 

- Red  : equipment  not  running  (or  tripped);  valve  closed 

- Both  green  and  red;  intermediate  state  (MOV's). 


j 


J. 
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- Blue  : equipment  not  responding  to  remote  command  1 may  or 

> may  not 

- Amber  : equipment  under  local  control  J be  used 

This  format  should  be  again  optimized  for  8 tags.  Each  keyboard 
should  include  separate  keys  (shared  by  all  tags)  for  the  execution 
of  contnands  such  as  start,  stop,  close,  open.  Operation  of  MOV's 
would  normally  require  3 keys  (open,  close,  stop).  Operation  of 
a two  state,  motor  driven  equipment  (such  as  a pump), will  only  re- 
quire two  keys  (stop,  start). 

Single  tag  displays 

These  displays  are  very  seldom  used  by  the  operator  and  are 
mainly  intended  for  application  engineers. 

From  this  type  of  display,  operators  may  have  access  to  data 

such  as: 

- Alarm  limits 

- Applicable  indexes  for  deviation  type  overview 

- Tuning  constants 

- Loop  parameters  (ratio,  bias,  filter  time  constant,  output  limits, 
integral  limits  etc.) 

Interlocks  preventing  free  access  should  be  at  least  applicable  to 

- Alarm  limits 

- Tuning  constants 

- Integral  limits 

Special  single  tag  displays  should  also  be  available  as  for  example  for  tank 
gauging  applications.  These  displays  should  be  normally  limited  to  30-40  for 
onsites oppl  icat  ions.  Tn  general  they  will  include  more  than  one  input  (e.g., 
level  a nd  temperature  of  a tank)  as  well  as  calculated  variables  (total  gross 
volume,  total  net  volume,  specific  gravity  etc.) 


Trend  Formats 


• Multitrcnd  Displays 

These  display  formats  a.  intended  to  replace  pen  recorders.  The  display 
characteristics  of  these  formats  can  be  summarized  as  follows: 
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- The  format  should  bo  capable  of  supporting  simultaneous  trend  dis- 
plays of  a number  of  variables  at  least  equal  to  the  max.  number  of 
tags  used  in  multitag  formats. 

- It  should  be  possible  to  configure  these  formats  in  advance  in  the  same 
tenner  as  with  the  multitag  displays  and  with  the  same  ease. 

- Any  screen  could  be  selected  for  displaying  trends,  either  by  using 
the  standard  keyboard  or  one  of  the  special  function  keys  of  the 
matrix.  A second  function  key  should  be  normally  used  to  predispose 
the  screen  to  automatically  accept  requests  for  presentation  of  "as- 
sociated" displays  generated  from  other  screens. 

- Call-up  of  multitrend  displays  should  be: 

+ Via  the  pushbutton  matrix  of  the  screen  selected  for  trend  displays 
(single  action). 

+ Via  the  keyboard  (e.g.,  "trend"  function  key  & display  code). 

+ Via  association  with  other  display  formats. 

- The  same  considerations,  listed  for  the  bar  graph  overview  and  con- 
cerning the  grouping  of  tags,  should  also  be  applicable  to  these  dis- 
play formats.  In  general,  however,  a lower  degree  of  association  is 
expected  between  the  grouping  of  tags  for  overview  or  multitag  format 
and  multitrend  formats. 

- The  number  of  pages  to  be  provided  at  this  level  of  display  should  be 
consistent  with  the  size  of  the  data  base.  As  a minimum  it  should 
cover  207.  of  the  total  number  of  control  and  information-only  tags. 

- The  library  of  pages  should  be  addressable  from  the  pushbutton  matrix 
whenever  the  associated  screen  is  displaying  a multitrcnd  format.  The 
active  buttons  should  be  clearly  identified. 

- The  "display  association"  feature  (see  multitag  displays)  should  also 
be  applicable  to  multitrcnd  displays. 

- All  variables  displayed  on  a multitrcnd  format  will  always  appear  with 
a minimum  of  2 hours  history  and  will  revert  automatically  to  real  time 
trending. 

- In  general,  a 5 to  6 sec.  updating  is  considered  adequate  for  any  vari- 
able. Slower  updating  of  the  order  of  10  or  20  sec  may  certainly  satisfy 
a large  number  a process  variables,  but  cannot  be  generalized.  On  the 
other  hand  the  need  to  display  the  entire  history  at  a high  sampling  rate 
is  very  seldom  required. 
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Based  on  the  above  considerations,  the  following  requirements  repre 
sent  a generalized  attempt  to  satisfy  a variety  of  considerations  as- 
sociated with  a consistent  presentation  of  multiple  trends  of  variables 
having  different  process  lags. 

+ The  displayed  history  can  be  shown  in  two  portions,  having  dif- 
ferent resolution  in  terms  of  sampling  rates. 

+ The  "high"  resolution  portion  should  consist  of  the  last  10-15 
minutes,  where  each  displayed  point  will  correspond  to  a sample 
taken  every  5-6  sec. 

+ The  "low"  resolution  portion  should  consist  of  the  remaining  time 
interval  (105-110  min.);  each  displayed  point  will  now  correspond 
to  samples  at  20  sec.  intervals. 

+ The  two  portions  should  be  clearly  distinguished  (e.g.,  by  color 
coding  of  the  corresponding  time  scales  on  the  horizontal  axis). 

- More  than  one  trend  can  be  displayed  on  the  same  screen  sector  using 
different  color  for  each  trend. 

- It  should  be  possible  to  change  the  display  content  on-line  by  deleting, 
adding,  or  substituting  variables  to  be  trended. 

Any  variable  available  within  the  distributed  data  base  could  be  assigned  to 
multitrend  formats.  It  should  be  kept  in  mind,  however,  that  the  purpose  of 
this  display  format  is  to  present  the  operator  with  the  type  of  information 
he  gets  today  from  multipen,  shared  recorders.  For  the  6ame  reason,  the  display 
should  be  kept  as  simple  as  possible  and  should  not  emulate  the  characteristics 
of  recorder  charts. 

The  information  displayed  with  each  trend  should  include: 

- Tag  I.D. 

- Short  description  (optional  and  not  exceeding  8 character  max.) 

- Time  marks  (1/2  hr  interval)  on  horizontal  axis. 

| 

All  scales  should  be  linear  0 to  100%  (4  divisions  only)  and  should  correspond 
to  the  measuring  span  of  the  field  transmitter. 

• General  Purpose  Trends 


It  should  be  possible  to  display  the  history  of  a variable,  whether  independent 
(i.e.,  having  tag  status)  or  associated  with  a tag  (input,  calculated  variable, 
calculated  target  etc.)  in  trend  format. 
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The  display  requirements  for  such  trends  may  be  quite  different  from 
those  applicable  for  multitrend  displays.  In  general  the  display 
characteristics  should  include: 

- Possibility  to  use  expanded  scale  (in  engineering  units). 

- Different  time  sea le  options . 

The  digital  information  displayed  with  such  trends  may  in  general 
include  the  following: 

- Digital  value  of  variable  (last  sample) 

- Tag  I.D.  and  description 

- Scale  in  engineering  units 

- Time  marks 

More  than  one  trend  may  be  displayed  on  the  same  screen.  However, 
time  scale  syncronization  is  not  a requirement. 


Graphic  Display  Capability 


As  mentioned  in  Part  I,  graphic  presentations  of  process  flow 
diagrams  on  video  screens  is  extensively  used  in  Oil  Movement  & Storage 
(OM&S)  applications.  It  has  proven  a very  powerful  tool  and  significantly 
assists  the  console  operator  in  preforming  the  assigned  tasks. 


This  specification  addresses  graphic  presentation  of  process  units 
and  flow  diagrams  for  onsites  applications.  It  is  generally  believed  that 
such  presentations,  if  properly  engineered,  can  certainly  assist  the  console 
operator  to  better  visualize  the  operating  conditions  of  a process  unit  dur- 
ing unit  monitoring  and  to  reach  a better  understanding  of  the  impact  of  his 
manipulations  under  "interactive"  mode. 


Because  of  certain  specific  requirements  associated  with  these 
displays,  a separate  screen  may  have  to  be  used  eventually.  This  is  not, 
however,  a design  objective  and  to  the  maximum  extent  possible,  the  require- 
ment of  maintaining  total  flexibility  in  using  any  available  screen  should 
remain  the  basic  design  criterion. 


In  order  for  this  type  of  displays  to  be  effective,  the  process 
flow  diagrams  should  be  stripped  down  to  a minimum  level  of  detail  and  be 
organized  in  a logical  sequence.  In  addition,  the  display  should  contain 
enough  Information  as  to  become  self  suf ficient-at  least  to  the  maximum  ex- 
tent possible.  Figure  4 illustrates  an  example  of  simplified  P&1D  used  for 
reference  by  console  operators  and  gives  an  idea  of  the  degree  of  detail 
that  may  be  required. 


J 
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• I>  1 j* p 1 *i y Requirements 

The  basic  requi  remonts  for  this  t y |>«  • of  display  format  at*  sowAr  t ■•<! 
bo  low: 

- Tito  display  should  bo  fully  Interactive,  l.e.,  the  oparator  should  he 
able  to  Initiate  an  Inter  ac  t t vo  nunle  ft  >m  this  i.'splay  alone 

- Tbo  process  Input  for  all  'ags  should  br  update  , on  t’.*  screen.  text 
to  tbo  instrument  symbol. 

- Selection  of  control  tag*  for  Interactive  mode  should  he  prafcrabl 
via  light-pen  or  similar  technlqi  •*  . 

- A selected  control  tag  should  be  displayed  on  a dedicated  sector  of 
tbo  screen  (work  areal  for  parameter  manipulation  (set  point,  mods, 
output  etc).  Those  changes  should  be  carr led-out  from  the  associated 
keyboard . 

- Textual,  symbolic  and  color  coding  should  bo  used  to  the  maximum  extent 
possible  to  minimize  screen  overloading.  In  general: 

•t  The  loop  function  (Temperature,  Pressure,  Flow,  etc.)  should  1* 
Identified  hv  I ho  shape  representing  the  instrument. 

t The  tag  l.D.  should  ho  simplified  (unit  code  can  be  shown  with  the 
title  of  the  display;  loop  function  can  he  identified  by  the  shape). 

+ Color  ceding  should  he  used  to: 

- reinforce  symbolic  coding 

- indicate  status  of  equipment  (e.g.,  in  service;  out  of  service) 

- indicate  abnormal  conditions  (Including  alarm  status) 

+ blinking  should  he  associated  with  alarm  conditions  or  equipment  mal- 
functions . 

- The  library  of  available  pages  should  he  preferentially  addressable  via 
two  or  morcsuccossivehlerarchlc.il  overview  levels  of  Increased  detail, 
displayed  In  schematic  block  diagram  format.  Passage  from  an  overview 
level  to  the  desired  schematic  diagram  should  ho  again  via  light-pen 
selection  or  similar  technique. 

- Alternative  methods  of  selection  are  not  excluded,  such  as  via  tho 
pushbutton  matrix  in  combination  wi  th  success Ive  levels  of  area/unit 
directories  displayed  on  the  screen,  or  via  display  association. 

In  any  case,  each  individual  page  of  the  library  of  schematic  process 
diagrams  should  also  he  addressable  from  the  consolo  keyboard,  entering 
the  appropriate  code. 


• Building  and  maintenance 


It  la  recognized  that  building  such  display  formats  as  well  as  maintain- 
ing them  up-to-date  to  reflect  various  alterations  could  represent  a 
•lgnif  leant  effort  to  the  user. 

In  general,  building  the  schematics  from  a keyboard  via  a user  defined 
library  of:-hapes,  is  rather  difficult  compared  to  techniques  where  the 
schematic  is  drafted  and  automatically  digitized  and  stored  in  bulk 
memory.  On  the  other  hand,  the  ability  to  alter  the  schematics  from 
a keyboard  appears  to  ofier  advantages  in  terms  of  maintaining  them 
up-to-date.  Consideration,  therefore,  should  be  given  to  a combination 
of  both  methods. 

• Other  graphic  displays 

In  general,  the  user  should  have  the  capability  of  building  different 
types  of  graphic  displays  such  as  block  diagrams  of  control  schemes, 
special  bar  graph  profiles  or  other  formats  be  might  wish  to  experiment 

with. 

Pushbutton  Matrix 

The  multipurpose  role  of  this  addressing  tool  requires  that  Its 
design  is  given  special  consideration.  The  general  requirement  is  for  a 
flexible  and  self-adaptable  addressing  system,  having  the  purpose  to  simplify 
the  console  procedures  from  an  operator's  point  of  view.  As  pointed  out 
before,  it  should  not  he  viewed  as  a simple  matrix  of  pushbuttons  but  as  a 
matrix  of  elements  capable  of  adapting  automatically  to  the  display  format  bein 
presented  on  the  screen.  This  self  adaptation  should  be  in  terms  of  active/ 
inactive  status,  illumination,  textual  coding  (labels)  and  color. 


Summary  of  Basic  Requirements 

• The  operator  console,  as  defined  in  this  specification,  ie  an  integrated 
work  station  based  on  a modular  and  expandable  system  supporting  a number 
of  identical  display/manipulative  sets.  The  design  objective  is  that 
each  set,  consisting  of  a screen  and  entry  keyboard,  should  be  able  to 
support  any  type  of  display  format.  On  the  other  hand,  the  ability  to 
assign  any  screen  to  specific  typo  of  display  formats  should  be  provided. 

• To  the  maximum  extent  possible,  call-up  procedures  and  passage  from  one 
hierarchical  level  of  display  to  the  next  should  be  by  single  action. 
Passage  from  one  display  to  another  at  the  same  level  of  display  hierarchy 
should  be  simple  and  fast  and  should  also  be  based  on  display  association, 

• For  a console  intended  to  be  used  as  the  solo  operator  interface,  the 
reliability  aspects  of  the  design  assume  primary  importance  and  should 
address  the  following: 


I 
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- Interactive  failure  modes,  graceful  degradation  and  fast  recovery 

- Communication  with  the  outside  world 

- Communication  between  components  of  the  console 

A total  failure  of  the  operator  interface  is  unacceptable. 

• The  display  and  address  capability  of  each  console  should  be  consist- 
ent with  the  total  data  base  of  the  control  system  so  that  any  process 
area  can  be  assigned  to  any  console. 


Additional  Considerations 

The  design  of  a console  should  also  take  into  account  the  follow- 
ing considerations. 

• Ease  of  maintenance 

• Auxiliary  space  requirements  for  temporary  storage  of  manuals,  logs,  etc. 

• Protection  of  work  area  against  accidential  spills  (soft  drinks,  coffee) 

The  design  of  the  keyboard  should  be  kept  uncluttered  and  organized  such  that 
seldom  used  keys  are  kept  separate  from  often  used  ones.  The  keyboard  must  be 
of  rugged  construction  and  keys  should  withstand  rough  treatment. 

The  screens  should  be,  in  general,  protected  against  glare  but  this 
protec t ion  shou 1 d be  designed  such  that: 

• Does  not  interfere  with  the  readability  of  displayed  information  or  the  screen 
interaction  with  special  addressing  tools,  such  as  light-pens. 

• Matches  the  conditions  of  the  control  room  interior  illumination.  The  control 
room  illumination  should  be  preferably  adjustable  from  the  console  (ability 
to  dim  the  lights,  turn  on/off  spotlights,  etc.). 

Engineer's  Console 

• The  engineer's  console  is  considered  a special  purpose  tool  that  should  access 
the  entire  data  base  and  should  be  used  for: 

- File  building 

- Setting-up  or  modifying  control  strategies 

- Testing  the  behavior  of  new  control  schemes 

• This  console  should  be.  in  general,  a portable  device  able  to  communicate 
with  the  high  speed  bus  over  a distance  of  300  ft  (without  modems).  As 

a minimum,  it  should  consist  of  a keyboard  and  video  screen,  but  in  general 
does  not  have  to  be  a self-supported,  "smart"  terminal.  It  should  rather 
be  considered  as  a "shared"  peripheral  of  the  distributed  computer  system. 
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• The  reliability  requirements  should  be  similar  to  those  listed  for 
remotely  installed  consoles. 

• It  is  envisioned  that  several  of  these  terminals  (perhaps  as  many 
as  six  or  seven)  will  be  used  throughout  the  system. 

• The  engineer's  console  should  be  totally  independent  from  the  operator's 
console.  It  may  eventually  be  used  as  the  special  purpose  plug-in  ter- 
minal to  configure  the  operator's  console  data  base  but  this  should  not 
be  considered  a must.  In  general,  however,  it  should  be  able  to  access 
the  operator's  console  data  base,  directly  or  indirectly  over  the  high 
speed  communication  bus. 

t As  a minimum  the  engineers  console  should  be  able  to  display  the  basic 

formats  of  the  operator's  console.  It  is  not,  however,  required  that  this 
console  supports  the  interactive  alarm  features,  special  addressing  tools 
and  cross-reference  features  of  display  association. 
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CONTROL  STRATEGY 

Under  Computer 
Control 


(A) 


Under  "Backup” 
Control 


C/M/A-l 


CONTROL  (A): 


CONTROL  (B): 


Temperature  cascading  flow 

Flow  input  may  be  linearized  and  corrected  for 
temperature  and  pressure 

Under  bacrip  control,  temperature  loop  outputs 
directly  to  valve. 

Flow  Input  becomes  non-control  and  is  not  conditioned 
Temperature  loop  requires  operator  intervention  to 
be  commissoned  in  "auto"  mode. 


FIGURE  2 

EXAHTLE  OF  "BACKUP"  CONTROL  STRATEGY 
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PURDUE  EUROPE 


European  Regional  Organization 
of  the  International  Purdue  Workshop  on 
Industrial  Computer  Systems 


TC  6 

Technical  Committee  on 
Man-Machine  Communications 


AUTOMATION  AND  MAN-MACHINE  COMMUNICATIONS 


AIMS  AND  ACTIVITIES  OF  TC6 


JUNE  1977 
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AUTOMATION  ANO  MAN/MACHINF  COMMUNICATIONS 
AIMS  AND  ACTIVITIES  OF  TCP 


Trends  in  the  design  of  industrial  computer  systems 


There  has  been  a gradual  development  in  high-level  auto- 
mation of  industrial  production  processes,  starting  in 
electrical  power  generation,  petroleum  and  chemical  sec- 
tors and  spreading  to,  amongst  others,  the  steel  industry, 
assembly  operations  and  public  transport. 


During  the  last  few  years,  however,  developments  within 
the  scope  of  industrial  computing  exercise  a consider- 
able influence.  A variety  of  devices,  such  as  micropro- 
cessors and  visual  display  units,  are  now  available  for 
industrial  and  non-industrial  use.  Their  costs,  compared 
to  the  cost  of  labour,  have  become  so  low  that  widespread 
application  for  enhancing  productivity  is  unavoidable. 

This  dramatic  development  of  technology  has  created  a 
situation  in  which  automation  systems  are  radically 
different  for  new  plants.  New  designs  are  heing  intro- 
duces without  a thorough  knowledge  based  on  prior  ex- 
perience. This  is  clearly  apparent  in  the  application 
of  multiple  cathode-ray  tube  displays  for  process  super- 
vision and  the  use  of  distributed  computing  networks. 

A fundamental  gap  is  emerging  between  the  revolutionary 
rate  at*  change  in  machine  technology,  and  the  incorpor- 
ation of  human  factors.  These  encompass  the  existing 
knowledge  about  human  skills,  proven  methods  for  ana- 
lysing human  performance  and  the  understanding  of  human 
attitudes  towards  automation. 


. ' ..."  . r .. 
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The  problem  is  aggravated  by  the  upgrading  of  plants  and 
the  increasing  complexity  of  processes  owing  to  energy 
and  material  recycling.  Narrowing  profitability  margins 
put  a heavy  emphasis  on  production  within  tolerance  li- 
mits and  on  coping  effectively  with  abnormal  conditions. 
The  safety  aspect  of  plant  operation  is  also  gaining  im- 
portance. due  to  legislation  in  an  age  of  growing  public 
awareness  of  and  concern  with  the  environment  in  the 
widest  sense. 

The  operator,  whose  main  task  is  now  to  supervise  process 
operation,  has  a key  role  in  this  development.  His  opera- 
tional practices  and  procedures  are  strongly  influenced 
by  the  design  of  the  man-machine  interface.  Careful  design 
of  the  man-machine  interface  is  therefore  crucial  to  the 
success  of  the  operator-process  system.  But  conflict  can 
arise  between  the  natural  tendency  to  assign  as  much  re- 
sponsibility and  control  to  machines  as  technological ly 
possible  against  the  need  to  enable  the  human  operator 
to  maintain  meaning  in  an  understanding  of  his  job  - to 
provide  for  his  interpretive  skills  in  decision  making  and 
for  his  ultimate  responsibility  for  plant  control  and  for 
plant  safety. 

These  various  factors  mentioned  above  demonstrate  the  need 
for  s 

desipn  procedures  which  contribute  to  acceptable  tasks 
for  human  operators 

- techniques  in  designing  interfaces  to  match  human 
abilities 

- utilisation  of  information  describing  human  performance. 


i . 
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Tne  following  nwdns  will  be  used: 

Survuy  uf  sjuccqssbs  and  failures  in  thu  design  of  MMlf  i 

Uete rmi nati on  of  tne  parameters  and  features  critical 
for  good  MHC  design  and  the  incorporation  of  these  in 
a series  of  guideline  documents,  for  example  on  the 
methodology  and  tecnniques  for  design,  implementation, 
and  for  training! 

Cooperation  with  other  TCs  in  matters  concerning  MMC 
at  all  levels  of  system  oesign,  imp  lemen  tati  on  and 

use  i 

Dissemination  uf  the  results,  encouraging  discussions 
with  and  acceptance  by  users,  national  and  international 
groups  and  stunaardisation  bodies. 

Past  and  current  activities  are  in  three  areas: 

Prepai'ation  of  the  results  from  a questionnaire  which 
has  been  circulateu  to  various  buropean  industries  to 
assess  experience  and  attitudes  to  problems  in  interface 
design,  from  basic  philosophy  to  realisation.  An  analysis 
of  the  common  problem  areas  will  be  used  to  formulate  a 
working  remit  based  on  users’  needsi 

Preparation,  in  cooperation  witn  the  parallel  American 
TC,  of  a set  of  guiuelines  which  will  offer  procedural 
and  substantive  recommendations! 

ts tab  1 isiiment  of  contacts  with  industry,  national  lab- 
oratories and  universities  engaged  in  the  field  of 
PMC  throughout  Lurore. 
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In  son's  respects,  human  performance  is  poorer  than  that 
of  a machine,  o.p.  in  making  consistent  docisions  or  cal- 
culations. But.  design  for  complementary  functions  of  hu- 
man operators  and  equipment  can  exploit  the  best  features 
nf  both.  In  no  industry  is  this  more  apparent  than  in  that 
of  nuclear  energy  where  risk  analysis,  safety  reporting 
and  incident  analysis  are  becoming  increasingly  important. 
Many  studies  have  been  undertaken  investigating  human 
fallibility  and  me. ins  of  allowing  for  it  through  good  de- 
sign practice.  Those  considerations  are  equally  appropriate 
to  the  many  other  process  industries  for  systems  design 
to  be  safe,  acceptable  in  operational  requirements  for 
humans,  and  to  bo  cost  effective. 

The  Role  of  the  It"  on  Man-Machine  Communications 


The  Technical  Committee  consists  of  furopean  members  from 
a range  of  disciplines:  system  engineering,  software  de- 
sign, and  human  factors.  There  are  common  interests  with 
the  other  I’urdue  ! urope  TCs  and  links  with  the  parallel 
TCs  in  America  and  Japan  under  the  Purdue  In te mat i ona  1 
Workshop.  Through  its  composition  and  formal  relationships, 
the  Technical  Committee  is  thus  in  a unique  position  in 
f urope  to  investigate  and  influence  man -machine  communi- 
cations (MMC ) in  the  context,  of  developments  across  the 
field  of  industrial  computing, 

A joint  activity  with  the  parallel  American  TC  is  in  pro- 
gress, in  order  to  develop  an  approach  based  on  world-wide 
experience.  Prior  to  presenting  guidelines  to  professional 
groups  and  standardisation  bodies,  there  is  a need  to 
establish  a common  frame  of  reference  and  common  termino- 
logy for  both  vendors  and  users  to  improve  specifications. 
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The  aim  of  thn  Technical  Committee  in  to  improve  the  incor 
pomtion  of  user  characteristics  in  design,  through  the 
collection,  evaluation  and  dissemination  of  information 
and  experience. 


Plans  and  Future  Activities 

Plans 


Membership  of  the  Technical  Committee  is  on  a voluntary 
basis  and  consequently  the  acitivies  are  limited  by  the 
members’  normal  working  commitments.  This  results  in 
slower  progress  than  desirable,  with  the  risk  that  re- 
sults and  recommendations  may  be  superseded  by  events. 

The  alternative  is  to  seek  support  in  order  to: 

improve  communication  on  and  to  stimulate  activities 
in  research  and  development  in  MMC  activity  in  Curopei 

facilitate  surveys,  visits  and  seminars) 

- formalise  co-operation  with  the  CEC  to  increase  interest 
and  acceptance  of  these  issues  in  European  industry. 

A clerical  support  and  administration  centre  is  essential 
to  forming  a focus  for  European  MMC  activity  relevant  to 
the  industrial  rather  than  the  academic  sector.  Much  of 
the  university  study  in  this  field  is  industrially  sponsored 
but  resources  are  necessary  for  it  to  be  presented  in  a 
wider  context  of  applicability  across  industries.  Similarly 
resources  are  needed  if  data  and  information  held  by  various 
indus’ries  are  to  be  made  available  by  their  staff  in  a 
suitable  form. 


r 
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Thn  desipn  of  an  information  system  should  no  longer  be 
re  pnrdod  as  a naturally  emerpent  occurranco.  It  must  ba 
planned  and  monitored  throughout  the  desipn  process.  In 
time,  with  financial  support,  it  will  be  desirable  to 
sot  up  .m  information  aon/ico  which  can  advise  industry 
and  which  can  act  as  an  opnncy  between  industry,  univer- 
sities and  other  consultants. 

Activities 

Through  contacts  with  research  and  development  functions 
and  with  users,  current  practice  in  industry  will  be 
reviewed  and  will  be  rnlatnd  to  the  body  of  information 
available  within  tho  following  areas: 

The  practical  and  thaoretic.nl  constraints  of  equipment 
used  in  interface  dnsipn,  and  the  software  and  pro- 
cedures which  may  bo  used  in  riotermininp  its  appli- 
cations and  flexibility* 

The  information  requirements  of  processes  and  their 
control  and  the  impact  of  now  techniques,  e.p.  pre- 
dictive aids  for  control* 

The  influence  of  human  factors  upon  operational  practice 
proendures . 

In  order  to  further  a prowl np  awareness  of  those  issues 
and  to  promote  active  interest  in  their  i n vns t ipat ion , 
seminars  will  be  nrpaninnd  for  industrial  users  and  for 
representatives  rif  national  bndios.  The  seminars  will  be 
used  to  nnourn  appropriatn  direction  in  thn  Technical 
I'nmmi  t.t.nn  *r.  work  for  the  dnvelnpmnnt.  of  puitlnlinos.  Thn 
first  seminar,  proponed  to  he  hold  in  Unromhnr  1 H7/#  is 
under  discussion  and  will  bn  doalinp  with  tho  subject  of 
how  the  human  factors  in  MMl'  dnsipn  may  be  incorporated 
into  a dnsipn  process  at  a practical  level. 
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Development  of  a sat  of  guideline  documents  will  be  the 
principal  continuing  activity.  It  is  planned  that  their 
structure  will  be  suitable  for  providing  information 
to  senior  management  and  project  personnel  as  appropriate. 
The  guidelines  will  be  presented  as  a hierarchy  of  pro- 
cedures and  information  in  consultation  with  tho  other 
Purdue  Purope  TC3  to  establish  needs  and  priorities  with 
feedback  to  be  sought  from  national  engineering  societies. 


It  is  the  Committee’s  view 
pative  style  can  a genuine 
be  fostered  in  the  complex 
municat ions . 


that  only  in  this  partici- 
understanding  and  commitment 
field  of  man-machine  com- 


